Re: [Rats] New Version Notification for draft-lundblade-rats-eat-media-type-00.txt

[Anders Rundgren <[e-mail]>]

On 2022-07-18 21:38, Dave Thaler wrote:
> Thanks for submitting this draft.  I think the WG should adopt it as a WG document.

Hi Guys, feel free to adopt this as a WG document but you may read the following first.

There are reasons for using media types for providing additional type information.  However, there are also reasons for not taking this path which have not been discussed in any detail.

My main objection to this draft is that it departs from current best(?) practices:

1. There are gazillions of REST-based services out there using a single and non-parameterized mime-type (application/json).

2. FIDO attestations are already self-contained making them transferable over different transports as well as straightforward storing in databases or embedding in other objects.
   {
     "fmt": "apple",
     "attStmt": ...

   {
     "fmt": "tpm",
     "attStmt": ...


A "proper" solution should therefore (IMO...)
- be self-contained
- use a single mime type
- if signed, include the entire object (modulo the signature value itself) in the signature calculation


If there is a need figuring out the type of an object, before reading the rest, the way FIDO does this seems good enough.  As you may have noted, I have suggested a CBOR tag [*]
    211TBD([object type-id, object data])
intended to address this issue for a wide range of applications.  I would love to realize this as an RFC within the RATS or CBOR WG.

Cheers,
Anders

  *] This can be tried out at: https://test.webpki.org/csf-lab/create
The current implementation requires type-id to be a "string" and data to be a map {}.


> 
> I have reviewed it, and used it in the latest draft-ietf-teep-protocol draft (which during the last RATS meeting I said I would do).
> 
> I have just one wording suggestion.  In section 3 it says:
> 
>> The media types defined in this document include an optional profile
> 
>> parameter that can be used to mirror the eat_profile claim of the
> 
>> transported EAT.  Exposing the EAT profile at the API layer allows
> 
>> API routers to dispatch payloads directly to the profile-specific
> 
>> processor without having to snoop into the request bodies. 
> 
> That is of course true, but the justification can be even stronger by pointing out that it also allows use when the payload is not present in the message, such as in an Accept header (and indeed section 4 shows that).
> 
> Indeed, the TEEP protocol uses it in both Content-Type and Accept, just like in section 4.
> 
> Dave
> 
> 
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats