Re: [Rats] Call for adoption (after draft rename) for Yang module draft

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

So far the group has used the term "EAT" to refer to both the information model and data serialization expressions. When extending information model to YANG or some other serialization (e.g. ASN.1). Given the possibility for an IM expression to be realized by different serializations, what term should we give to the IM description? 

The term "Claim" has been used extensively. Do we want to agree to use "claim" to refer to anything that is an IM expression in RATS and "Token" for any serialization (realization) even if it isn't a JWT or CWT?  

Thx,
Ned

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

    Hi Michael,
    
    please see in-line.
    
    On 11.11.19 12:37, Michael Richardson wrote:
    > 
    > 
    > On 2019-11-11 5:57 p.m., Henk Birkholz wrote:
    >> Hi all,
    >>
    >> on one hand, we have to address the overlap between YANG and EAT
    >> information elements (statements & Claims) and how to deal with them
    >> (one obvious issue, for example, would be potential redundant
    >> information model content in two different drafts).
    > 
    
    Examples of the same information elements that are used in different 
    data models via Claims or statements:
    
    * EAT Time stamp / YANG clock info
    * EAT Origination / YANG attestation key cert, or
    * EAT Uptime / YANG tpm ticks
    
    > Can you give me an example, but I'm not getting the issue.
    > I think that we will be the first to attempt to use JOSE to sign a JSON
    > serialized YANG object, resulting in a JWT.  Well, technically, it's
    > probably not a JWT, because we aren't going to base64url it and put
    > periods between the pieces, I think.  It's just JOSE, but I don't mind
    > if we call it a JWT.
    
    As far as I know, simply wrapping a "JSON serialized YANG object" in 
    JOSE does not create a JWT. RFC 7951 is not based on RFC 7519. The 
    Base64/Base64URL confusion is limited to value representation in JSON 
    serialization, I think.
    
    > 
    > draft-ietf-anima-constrained-voucher does CBOR serialized YANG which is
    > signed with COSE.
    
    With CBOR serialization most things more straightforward and a tad bit 
    simpler. I do not think that we have any issues on the binary side of 
    things here. Or am I missing something obvious?
    
    > 
    > 
    >> On the other hand, Laurence's original point was the payload of
    >> conveyance protocols used by RATS. Specializations of this topic are
    >> apparently:
    >>
    >> * Web Tokens via YANG Interfaces, and
    >> * YANG modeled data via other conveyance protocols (other than *CONF)
    >> that can transport Web Tokens.
    >>
    >> There are examples of how YANG modeled data is used outside of *CONF
    >> protocols, for example MUD. We have to understand and agree about:
    >>
    >> * this is possible on a technical level, and
    >> * this is useful wrt to protocol scope, intent & semantics, I think.
    >>
    > 
    > MUD (RFC8520) does it, but so does ANIMA vouchers (RFC8366).
    > Again, data-at-REST described by YANG.
    > 
    > But the document in question does not seem to be data-at-rest, but RPC
    > access via *CONF protocols to TPM 2.0 objects, so I feel that you are
    > further muddying this thread by asking the above question.
    > 
    > 
    > _______________________________________________
    > RATS mailing list
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/rats
    > 
    
    _______________________________________________
    RATS mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/rats