[Rats] terminology: claims and tokens was Re: Call for adoption (after draft rename) for Yang module draft

["Smith, Ned" <[e-mail]>]

Renaming this thread since it seems to have diverged.

What I think I heard is that the terminology should disambiguate between something that is a data model / information model expression (e.g. claim - at least for now) and something that is an encoding of the DM expression (e.g. token). Is there broad agreement that when the term 'token' is used it refers to a "wire-format" realization of Claim? 

This definition of Claim may not be universally shared within the IETF. Is this true? If not, what is the wire-format definition of claim?

Multiplicity terminology is another area of ambiguity. There are two plurals for claim namely "Claims" and "set of claim" or "set of claims" - I don't know if these are intended to be synonyms or if "set of claims" has multiple dimensions of plurality. 

It should follow that Tokens, "set of Token" and "set of Tokens" as expressions of plurality are the same as for claims et.al. only with the added requirement that there is a wire-format representation of it. 

The EAT draft defines claims that are plurals of claim - namely "nested EATs" and "submods". 
It is probably correct to say that a nested_EAT (claim or token) is a "set of tokens". As near as I can tell, the draft is defining the contents of the nested_EAT claim as a structure that is in a wire-format. It is reasonable to assume that the nested_EAT claim could be realized as a token (implying the outer most layer formatting needs to be applied).

I don't think I fully comprehend the submods claim so I may not represent it correctly. It appears to be a set of claims (or at least a set of names that corresponds to claims) that can be realized as a token. In this expression, the set of claims are realized as a set of strings rather than a set of tokens. 

Are there YANG expressions that exhibit similar or relevant properties in terms of Claim vs. Token and their plurals?

Thanks,
Ned

On 11/13/19, 3:55 AM, "RATS on behalf of Henk Birkholz" <[e-mail] on behalf of [e-mail]> wrote:

    Please find comments and replies in-line.
    
    On 13.11.19 12:44, Schönwälder, Jürgen wrote:
    > On Wed, Nov 13, 2019 at 12:25:21PM +0100, Henk Birkholz wrote:
    >> One reason for this - and I tried to express that carefully - is that just
    >> using the word "token" could be very confusing. We are using "Claim" as a
    >> synonym to "Assertion" at the moment. Outside of the IETF that makes a lot
    >> of sense. Inside the IETF, we still have to be a bit careful here, as
    >> "Claim" is well defined in Web Tokens - and it is a data model term
    >> (basically: a specific key value representation).
    > 
    > I looked into JWT and I think I roughly know what they mean by claim.
    > Now we have "assertion" (also not defined in your architecture draft).
    > Hmm.
    
    Yes. I am sorry it is this way. If you have a look at ITU-T 1252 Section 
    6.6 (free reference here: 
    https://www.itu.int/SG-CP/example_docs/ITU-T-REC/ITU-T-REC_E.pdf) it is 
    not that bad. But that is "outside IETF". Not every Attestation 
    Evidence, Endorsement or (let's not call it Reference Value to address 
    Dave's comment, but) Appraisal Policy? is using "Web Token Claims", they 
    all use Assertions. We will add text that highlights that in the scope 
    of the architecture these are synonyms and not the Web Token Claims.
    
    >   
    >> An EAT is a CWT (or JWT, not the point). So both are Claim sets that compose
    >> tokens. The architecture is intended to be representation (I am using this
    >> term to dance around the sanity rending serialization/encoding words, and to
    >> spare Rich some of the pain) agnostic. Claims in the architecture are
    >> therefore representation agnostic, too. Claims in tokens - by RFC definition
    >> - are not.
    > 
    > To me, it seemed like in JWT, we have 'sets of claims' and then these
    > claim sets are serialized into a string representation ('serialized
    > sets of claims') and the serialization is finally digitally signed and
    > encrypted, giving us a token. This works for me.
    > 
    > The notion of "claim sets that compose token" confuses me. If I compose
    > token, I get a "set of tokens". Yes, indirectly I get also a union(?)
    > of the claim sets included in the tokens.
    
    Bad wording. Readability. My weak spot as it seems. What I meant was 
    that (literally) a set of Claims in a JSON object compose a Web Token. 
    Very simple nothing more :) I think we mean the same. Please correct me, 
    if I am wrong.
    
    > 
    > Anyway, we need to get terminology worked out or we will not
    > understand what we are doing or worse we agree on something but
    > people interpret the agreement differently...
    
    We are in wild agreement here.
    
    > 
    >> I am not a super big fan of this compromise, but it found consensus, removed
    >> a blocker, and we were able to progress.
    > 
    > Progress is when we all agree on the same thing.
    
    There was. At some point. If it is not anymore, we can make this an 
    issue in the upcoming converged architecture I-D.
    
    > 
    > /js
    > 
    
    Viele Grüße,
    
    Henk
    
    _______________________________________________
    RATS mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/rats