Subject: [Rats] Info & Data Models

From: Laurence Lundblade <[email-masked]>
Date: Fri, 2 Aug 2019 09:34:53 -0700

From WG meetings, side conversations and reading it seems to me that “information model" is being used an a few ways by RATS folks:

1) One description common to several serialization formats
Idea here is that one primary description exists for an information element (e.g. each claim) and it is common to the serializations in CBOR, JSON, ASN.1 and so on. This is the classic definition in RFC 3444 and RFC 3198 and what was done in draft-ietf-rats-eat-01.

2) One info model for ALL of RATS
Idea is that there is only one info model in one document that is common for every draft output by the RATS WG. It would cover claims in tokens as well as information elements in conveyance protocols. Elements marked “P” in draft-birkholz-rats-information-model-00 are for conveyance protocol information elements and those marked “S” and “H” are claims.
 
3) That the payload claims/assertions need more sophisticated structure
Idea here is for more nesting, sub categories and rich structure for claims.  Note that EAT already has both nesting and sub modules. I have always thought they needed improvement, but they are still powerful as they are.

4) That there be more typing and abstract data structures
Idea here is we define some generic types like hashes, date stamps, ways to list SW components in the abstract. Then different concrete claim instantiations can use them. So can claims registered with IANA.

I think 1) is essential because we clearly need multiple serialization formats, at the minimum CBOR and JSON. I thought this was the main reason our charter mentions info and data models.

I think 2) is impractical because the span is too large. There will be several RATS documents they will evolve at different rates and be authored by different people for different purposes. For example, claims will be in one document and conveyance protocols in another. We can’t be changing the one common info model document every time an information element in the claims or conveyance protocol document changes. 

I do however think we should try for one info model for the claims/assertions/evidence.

I always figured there would be a lot of work for 3) and 4), though it didn’t occur to me that they were implied by the info and data model separation (you can do 3 and 4 without info / data model separation). At any rate, the means we use to express the info model will be the same as we use for 3) and 4). 

I’d like to do work on 3) and 4) in the context of the EAT draft and CDDL now. I hope that we will end up with a claims info and data model in CDDL like in the EAT draft and separate from the conveyance protocol, but if we don’t this work on 3) and 4) will still be good useful work. I think the work on 3) and 4) also lines up with the questions Ned is raising about signed and not signed claims.

LL