Re: [Rats] Call for Adoption: EAT draft

[Henk Birkholz <[e-mail]>]

Hello Kathleen,

I just posted a list of recommendations wrt the EAT I-D. Not all of 
these are editorial, I think.

Viele Grüße,

Henk

On 5/23/19 3:49 PM, Kathleen Moriarty wrote:
> Chair hat off -
> 
> On Thu, May 23, 2019 at 7:54 AM Hannes Tschofenig 
> <[e-mail] <mailto:[e-mail]>> 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.
> 
> 
> I'd say it is a CWT.  CWT was built so that you could add new claims and 
> the plan for EAT is to register these.  If editors agree, we are down to 
> editorial changes on a well developed specification.  I support adoption.
> 
> Best regards,
> Kathleen
> 
> 
>     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 <[e-mail] <mailto:[e-mail]>> On
>     Behalf Of Carsten Bormann
>     Sent: Mittwoch, 22. Mai 2019 21:25
>     To: Kathleen Moriarty <[e-mail]
>     <mailto:[e-mail]>>
>     Cc: [e-mail] <mailto:[e-mail]>
>     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
>     [e-mail] <mailto:[e-mail]>
>     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.
> 
> 
> 
> -- 
> 
> Best regards,
> Kathleen
> 
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats
>