Re: [Rats] Call for Adoption: EAT draft

[Kathleen Moriarty <[e-mail]>]

Chair hat off -

On Thu, May 23, 2019 at 7:54 AM Hannes Tschofenig <[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]> On Behalf Of Carsten Bormann
> Sent: Mittwoch, 22. Mai 2019 21:25
> To: Kathleen Moriarty <[e-mail]>
> Cc: [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]
> 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