Subject: Re: [Rats] Call for Adoption: EAT draft - forking OAUTH + RATS thread

From: "Smith, Ned" <[email-masked]>
Date: Fri, 24 May 2019 19:34:38 +0000

Considering the question whether a token is a protocol message, document, payload or something else relative to OAuth and RATS because of the semantics that OAuth may have ascribed to CWT/JWT structures possibly doesn't need to be debated much until there is clarity regarding an information model that describes a collection of attributes that reasonably captures trustworthiness semantics. 

How they are conveyed, though within scope for RATS, doesn't necessarily need to be fully explored in order to have meaning conversation about an information model IMHO. 

Use of OAUTH with RATS seems like an interesting possibility that could be described in a draft. I expect such a draft would consider the interaction between the 'device' and AS as the point where attestation occurs. I.e. the 'device' is the Attester and the AS is the Verifier. The RS is therefore a Relying Party. OAuth uses CWT tokens to represent interactions between the Verifier and Relying Party. The current set of RATS drafts seem to be focused on Attester to Verifier interactions and use of CWT in that exchange seems to differ from OAuth convention. 

My impression of why OAuth device to AS interactions didn't initially try to use a token is because there are many existing authentication protocols that make sense to leverage. Similarly, there are many possible ways attestation could occur (as evidenced by the current set of drafts) that could be reasonable. Since an information model doesn't (on purpose) define a token or some other serialization structure, it is reasonable to assume the information model could inform both the conveyance between Attester and Verifier as well as between Verifier and Relying Party. They wouldn't necessarily need to use a common serialization and conveyance protocol binding method.

Regards,
Ned

On 5/23/19, 4:54 AM, "RATS on behalf of Hannes Tschofenig" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Carsten,
    
    You have been around when CWT defined but let me provide a history for those who weren't.
    
    The CWT was defined in ACE to correspond to a JWT. CWT uses CBOR together with COSE while the JWT uses JSON with JOSE.
    The CWT spec aimed to provide an easy mapping of claims already defined for the JWT. The JWT, a standardized access token format, is widely used in OAuth deployments and because ACE-OAuth uses, as the name indicates, OAuth as a foundation it created a "more lightweight version" of the JWT in form of the CWT. Defining an alternative token format for use with OAuth was possible because in the OAuth architecture the format of the access token is opaque to the OAuth Client.
    
    The CWT and the JWT have been defined for the OAuth authorization framework but they have later been used in other context too. Is this useful? It seems that the idea of having signed/encrypted/MACed claims is something people want to use even if different claims are used in different environments. Do they use different names then for these tokens (similarly what we do here with EAT)? Of course. People working in standardization like to come up with new names. That's why there are things like the "protection API access token (PAT)" or the "persisted claims token (PCT)".
    
    Is a token, like the CWT or the JWT, now a protocol message, a "document" or what? If you don't send it around then it does not seem to be a message. Not sending a token anywhere wouldn't be too useful either. The question I have is: does it matter? From a practical usage point of view you will have to send it around and it will be part of some message. I personally don't call it message or protocol but that's just me. There are claims defined for CWTs and JWTs that provide some meta-data, such as allowing to restrict its validity (time-based and even to a one-time use), or information that indicate when it was created.
    
    The main use case for attestation is a bit different than OAuth or ACE-OAuth because in OAuth/ACE-OAuth the access token gets created by the Authorization Server and is consumed by the Resource Server. While this is a possible use case also for RATS (when combined with an OAuth-based system, as folks in the OAuth group had suggested), the main use case (at least from my point of view) is that a device creates the token and then passes it on to the party that wants to verify it.
    
    If the EAT document uses the same structure as a CWT but defines new claims should you therefore say that "it is" a CWT or should one rather say "it is like" a CWT. I think it a matter of taste. I do not care - pick something.
    
    So, can you use claims defined already in an EAT token? Sure, you can. Will all the claims defined in the past be useful for an attestation context? Probably not. Will there be organizations defining profiles what claims they expect to see in an attestation token in a given deployment? Absolutely. GP, for example, is already working on it.
    
    In a nutshell: EAT is a simple effort and that's a good thing. This is why we implemented it and it is waiting for you to use it.
    
    Ciao
    Hannes
    
    -----Original Message-----
    From: RATS <[email-masked]> On Behalf Of Carsten Bormann
    Sent: Mittwoch, 22. Mai 2019 21:25
    To: Kathleen Moriarty <[email-masked]>
    Cc: [email-masked]
    Subject: Re: [Rats] Call for Adoption: EAT draft
    
    > The Entity Attestation Token (EAT)
    > https://datatracker.ietf.org/doc/draft-mandyam-rats-eat/
    >
    > This begins a 2 week period to determine interest in adopting this draft as a working group item.  The poll will close on May 24th EOD PDT.
    
    Hi Kathleen,
    
    I am definitely interested in this work.  This is important, and I’d like to be able to convince myself we are doing it right.
    
    I apologize for maybe being a bit slow on the uptake, but currently I don’t have enough data to make a decision that the present document is on the trajectory yet where I’d normally ask for WG adoption.  Maybe this adoption call simply is a few weeks (draft revisions) too early.
    
    While we can fix a lot of details in the WG process, I’d like to understand some fundamentals before committing to the trajectory I don’t understand.
    
    For instance, I’d like to understand whether an EAT is a token or a protocol message in some as yet undescribed protocol.  E.g., there is the 11, nonce.  Is this the same thing that would be 7, cti in RFC 8392?  Or is it really something that is about an attestation protocol?  If this is a nonce, what does the “nonce” mean?  A single-use token?  A nonce that isn’t quite a nonce but only can be reused in a limited context?  How does the nonce bind to that context?
    
    More generally, I’d like to understand whether an EAT *Is* a CWT, or *Is like* a CWT.
    Can I put in an “exp” claim?  If yes, why do we need a new CBOR tag for something that essentially is a CWT?  Wouldn’t it be useful to explain when a CWT is an EAT and when it is just a plain CWT?  Tagging outside the COSE sign/mac isn’t enough (an attacker can change the tag and make a confusion attack).  Is this spec really the place to define a “loc” claim and its subclaims?  Is subclaims a concept that is only for EATs or is it for CWTs in general?
    
    I could go on explaining my lack of understanding here, but I think it should be clear that there are a lot of questions on *what* we are doing here (as opposed to *how* we are doing it, which is what the WG process is good for nailing down).  A couple of iterations on this document might allow us to make a much better case that this is indeed going to be one of the base documents for the WG.  Or maybe it really is a couple or three documents waiting to hatch from the eggshell.  We still have > 6 weeks before I-D deadline for Montreal to clean this up.
    
    Grüße, Carsten
    
    _______________________________________________
    RATS mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/rats
    IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
    _______________________________________________
    RATS mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/rats