Subject: [Rats] A media type for EAT

From: Thomas Fossati <[email-masked]>
Date: Fri, 28 Jan 2022 10:41:36 +0000

It looks like we are missing an explicit media type for EAT.

This could be also added separately, but it's probably better if we
bundled this with the EAT document before it's shipped to IESG.

One important thing is that we make the media type so that it can
optionally carry the EAT profile.  This allows HTTP/CoAP APIs to
dispatch to the right decoder without having to snoop into the payload.

Something like "application/eat+cbor" for the base thing and an optional
"profile" parameter that mirrors the profile claim value in the EAT.
E.g.: "application/eat+cbor; profile=1.3.6.1.4.1.etc"

PS: if there is agreement that this needs to be done I volunteer for
    preparing a PR

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.

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 28 Jan 2022 12:03:05 +0100

Hi Thomas,

I agree with the "we are missing an explicit media type for EAT" part. 
On that note, we are working on a -00 I-D about media-types for other 
types of Evidence in RATS right now.

If - and that is just a friendly fall-back option - this topic is 
perceived as yet another delaying activity for EAT publication, we would 
be able to cover that work item easily in the upcoming I-D, too.

I am highlighting this while taking into account the current tensions 
that are starting to come a up bit when discussions seem to be... 
straying from the course.

Viele Grüße,

Henk

On 28.01.22 11:41, Thomas Fossati wrote:
> 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.
> 
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 28 Jan 2022 11:26:18 +0000

Hi Henk,

On 27 Jan 2022 Henk Birkholz <[email-masked]> wrote:
> perceived as yet another delaying activity for EAT publication, we
> would be able to cover that work item easily in the upcoming I-D, too.
>

I agree there may be a timing problem here and that's why I volunteered
for preparing the PR :-)

And I also agree this could be done in a separate draft, it just feels
more "natural" if we could add it to the EAT doc.  That said I am not
adamant on where we solve this, as long as the gap is closed.

cheers, t

> > Something like "application/eat+cbor" for the base thing and an
> > optional "profile" parameter that mirrors the profile claim value in
> > the EAT.  E.g.: "application/eat+cbor; profile=1.3.6.1.4.1.etc"
> >
> > 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.
> >

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 28 Jan 2022 08:35:25 -0800

> I agree there may be a timing problem here and that's why I volunteered

Sounds good to me. Let’s see how it goes. If this becomes a blocking issue maybe it goes into another doc.

> more "natural" if we could add it to the EAT doc.

Yes, that’s definitely the better and more common way to do it.

>   That said I am not

Thanks!

LL

---

From: Ira McDonald <[email-masked]>
Date: Fri, 28 Jan 2022 11:55:10 -0500

Hi,

+1 to including the media type in the main  EAT spec - thanks Thomas.

Cheers,
- Ira

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 28 Jan 2022 18:48:02 +0000

Hi Ira, all,

PR: https://github.com/ietf-rats-wg/eat/pull/158

cheers,

On Fri, Jan 28, 2022 at 4:55 PM Ira McDonald <[email-masked]> wrote:
> On Fri, Jan 28, 2022 at 11:35 AM Laurence Lundblade <[email-masked]> wrote:
>>

-- 
Thomas

---

From: Michael Richardson <[email-masked]>
Date: Fri, 28 Jan 2022 14:13:59 -0500

> Something like "application/eat+cbor" for the base thing and an

Yes, and make sure you get a CoAP Content-Format :-)

    > the EAT.  E.g.: "application/eat+cbor; profile=1.3.6.1.4.1.etc"

Can you explain the use case here?
I don't understand how this would be used; it seems redundant.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 28 Jan 2022 19:51:01 +0000

hi Michael,

> Yes, and make sure you get a CoAP Content-Format :-)

Yep!

> I don't understand how this would be used; it seems redundant.

Yes, it is redundant, but it's very handy for when you have to use it
as a routing signal inside your (RESTful) API stack.

There you can have the API frontend to dispatch directly to the
profile-specific processors without having to implement the logic to
extract the profile by decoding the payload of the COSE Sign1 blob, a
couple of layers below where you actually are.

See for example how Veraison's CoRIM API frontend & decoders use a
very similar construct [1], [2], [3].

[1] https://github.com/veraison/veraison/blob/7ebedb0bdf172345a272c954ef88160581d79f6e/provisioning/api/handler.go#L94
[2] https://github.com/veraison/veraison/blob/7ebedb0bdf172345a272c954ef88160581d79f6e/provisioning/plugins/corim-tpm-enacttrust-decoder/decoder.go#L9
[3] https://github.com/veraison/veraison/blob/7ebedb0bdf172345a272c954ef88160581d79f6e/provisioning/plugins/corim-psa-decoder/decoder.go#L9

-- 
Thomas

---

From: Giridhar Mandyam <[email-masked]>
Date: Sun, 30 Jan 2022 02:00:30 +0000

I don't understand the intent of this proposal.

The introductory section of EAT clearly states that EAT can be a CWT or a JWT.  Both of these two data types already have corresponding media type registrations (https://datatracker.ietf.org/doc/html/rfc8392#section-9.2 and https://datatracker.ietf.org/doc/html/rfc7519#section-10.3, respectively).  I don't know why the existing media types are not sufficient, and nothing in the discussion below provides any insight to me either as to why another media type is required.

-Giri

-----Original Message-----
From: RATS <[email-masked]> On Behalf Of Thomas Fossati
Sent: Friday, January 28, 2022 11:51 AM
To: Michael Richardson <[email-masked]>
Cc: [email-masked]; Thomas Fossati <[email-masked]>
Subject: Re: [Rats] A media type for EAT

hi Michael,

Yep!

> I don't understand how this would be used; it seems redundant.

Yes, it is redundant, but it's very handy for when you have to use it as a routing signal inside your (RESTful) API stack.

There you can have the API frontend to dispatch directly to the profile-specific processors without having to implement the logic to extract the profile by decoding the payload of the COSE Sign1 blob, a couple of layers below where you actually are.

See for example how Veraison's CoRIM API frontend & decoders use a very similar construct [1], [2], [3].

--
Thomas

---

From: Henk Birkholz <[email-masked]>
Date: Sun, 30 Jan 2022 14:00:40 +0100

Hi Giri,

TL;DR while an EAT is a CWT, a CWT is not always an EAT. We need to be 
in support of protocols in constrained node environments and these might 
want to use EAT outside of FIDO or the Entity Attestation Protocol (and 
maybe even for more than for Evidence).

A hint to guide this discussion might be that EAT is trying to use... 
well an EAT for both Evidence and Attestation Results - and that would 
pull all the Claims in a combined Evidence an Attestation Result bucket 
(the CWT reg). While it might be (somehow - I think, barely) arguable 
that all Evidence Claims can be passed over by a Verifier to be 
Attestation Result Claims (again, I think that cannot "just happen" but 
must be annotated somehow using the "nested EAT mechanism"), the other 
way around that simply does not work.

I understand that this is what "profiling" is intended to be use for. 
And again, I get the way of thinking here. But for that (today super 
under-specified) thing to work between solutions, you have to look into 
the payload (because on payload level, this all is just a CWT).

In general, in order to help systems and protocols to process payload - 
especially in REST-like interactions - we use media-types (and of course 
the actually interesting content-format).

This is what this proposal does. It is in support of protocols to deal 
with Evidence and Attestation Results (beyond EAT! Please do not forget 
that there are billions of devices out there that create Evidence that 
is not EAT) to disambiguate Evidence and Attestation Results (because 
conflating them is very harmful) and to help simple protocols ind 
constrained environments to function in a secure manner.

Hence, I think it is a valuable and even necessary proposal. If you 
scope your requirements to the Entity Attestation Protocol or FIDO, I 
think you are correct, you do not need them.

I also think that this discussion might take up some time and therefore 
I very early indicated that we can deal with that in an upcoming media 
type I-D.

When we are writing up the media-types, what we - at minimum - have to 
establish is that we do not *contradict* the intended use of EAT, but 
rather *support* it.

Viele Grüße,

Henk

---

From: Thomas Fossati <[email-masked]>
Date: Sun, 30 Jan 2022 16:44:34 +0000

hi Giri,

>From the point of view of a Verifier that exposes a single API
endpoint to support different attestation formats (including multiple
EAT profiles), one wants to rely on standard HTTP/CoAP content
negotiation rather than resorting to MIME sniffing in order to
dispatch the incoming request to the right processor.  In that context
having a single application/cwt+cbor for everything EAT is less than
ideal, you need a more expressive type system.

cheers,
-- 
Thomas

---

From: Giridhar Mandyam <[email-masked]>
Date: Sun, 30 Jan 2022 17:30:24 +0000

> From the point of view of a Verifier that exposes a single API endpoint to support different attestation formats (including multiple EAT profiles), one wants to rely on standard HTTP/CoAP content negotiation rather than resorting to MIME sniffing in order to dispatch the incoming request to the right processor.  In that context having a single application/cwt+cbor for everything EAT is less than ideal, you need a more expressive type system.

We have run FDO interop events and have not determined that the lack of an EAT-specific media type results in interoperability issues.  Where we did see interop issues was with respect to use of canonical CBOR (https://datatracker.ietf.org/doc/html/rfc7049#section-3.9), which required spec clean-up and would not have been solved by designating an EAT-specific media type (because this was seen in non-EAT CWT data structures).

Perhaps you should look into your verifier implementation if you are having issues  in "dispatch(ing) the incoming request to the right processor".  In the meantime, I will state my opinion:  a standards specification is supposed to provide solutions to interoperability issues, not create interoperability issues where none exist.  A transmitter that designates an EAT with the existing CWT/JWT media types today is in compliance with the specifications as written, so there is no issue with interoperability regarding media types.  

What is your expectation if and when an EAT specific media type is defined?  Should a verifier reject a valid EAT token if it is designated with the existing CWT/JWT media type rather than the future EAT media type?  If so, why?  Can you point to any reports from interop events where developers could simply not support an attestation protocol without the designation of a new media type?    

-Giri

-----Original Message-----
From: Thomas Fossati <[email-masked]> 
Sent: Sunday, January 30, 2022 8:45 AM
To: Giridhar Mandyam <[email-masked]>
Cc: Michael Richardson <[email-masked]>; [email-masked]; Thomas Fossati <[email-masked]>
Subject: Re: [Rats] A media type for EAT

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

hi Giri,

> The introductory section of EAT clearly states that EAT can be a CWT or a JWT.  Both of these two data types already have corresponding media type registrations (https://datatracker.ietf.org/doc/ht…

From the point of view of a Verifier that exposes a single API endpoint to support different attestation formats (including multiple EAT profiles), one wants to rely on standard HTTP/CoAP content negotiation rather than resorting to MIME sniffing in order to dispatch the incoming request to the right processor.  In that context having a single application/cwt+cbor for everything EAT is less than ideal, you need a more expressive type system.

cheers,
--
Thomas

---

From: Anders Rundgren <[email-masked]>
Date: Sun, 30 Jan 2022 18:43:03 +0100

FWIW, in my own designs I use an old-school method and mark each object
with an "ObjectType" or similar while sticking to a single media type.

Receiving services then dispatch decoding etc. based on the ObjectType.

This concept is also useful when embedding potentially variant objects
in other objects.

Doesn't the "aud" key sort of provide this functionality already?

Anders

---

From: Giridhar Mandyam <[email-masked]>
Date: Sun, 30 Jan 2022 17:43:32 +0000

> TL;DR while an EAT is a CWT, a CWT is not always an EAT. We need to be in support of protocols in constrained node environments and these might want to use EAT outside of FIDO or the Entity Attestation Protocol (and maybe even for more than for Evidence).

Is this theoretical, or can you point to a specific example of a protocol that cannot ensure interop without new media types? 

Also, what is expected if constrained node cannot support HTTP or COAP?  How will the media type be used in that case?

> If you scope your requirements to the Entity Attestation Protocol or FIDO, I think you are correct, you do not need them.

Yes, it seems like a solution searching for a problem.  And it also creates a potential interoperability issue where none exists, because I don't think a transmitter that designates an EAT with the existing CWT/JWT media types would be considered non-compliant with the existing standards as the EAT will still be a CWT/JWT.

> I also think that this discussion might take up some time and therefore I very early indicated that we can deal with that in an upcoming media type I-D.

Sure - maybe a separate document on attestation media types could be taken up where other currently undefined media types (e.g. verification results, UCCS) can also be specified.  It would be useful also to provide a detailed explanation in such a document as to when to use a CWT/JWT data type and when to use a proposed EAT data type, and what the verifier should do if it detects an EAT designated with the existing CWT/JWT data type.  Also, it would be good to see how a media type would be used in a protocol that doesn't have existing support for media type data structures. 

 Thomas/Henk,

If you think it is important to define attestation media types, then I would strongly suggest you make a formal proposal to the Working Group rather than try to extend the EAT spec.  I don't think we can sufficiently address the issue in the EAT document alone.

-Giri

-----Original Message-----
From: Henk Birkholz <[email-masked]> 
Sent: Sunday, January 30, 2022 5:01 AM
To: Giridhar Mandyam <[email-masked]>; Thomas Fossati <[email-masked]>; Michael Richardson <[email-masked]>
Cc: [email-masked]; Thomas Fossati <[email-masked]>
Subject: Re: [Rats] A media type for EAT

Hi Giri,

TL;DR while an EAT is a CWT, a CWT is not always an EAT. We need to be in support of protocols in constrained node environments and these might want to use EAT outside of FIDO or the Entity Attestation Protocol (and maybe even for more than for Evidence).

A hint to guide this discussion might be that EAT is trying to use...
well an EAT for both Evidence and Attestation Results - and that would pull all the Claims in a combined Evidence an Attestation Result bucket (the CWT reg). While it might be (somehow - I think, barely) arguable that all Evidence Claims can be passed over by a Verifier to be Attestation Result Claims (again, I think that cannot "just happen" but must be annotated somehow using the "nested EAT mechanism"), the other way around that simply does not work.

I understand that this is what "profiling" is intended to be use for.
And again, I get the way of thinking here. But for that (today super
under-specified) thing to work between solutions, you have to look into the payload (because on payload level, this all is just a CWT).

In general, in order to help systems and protocols to process payload - especially in REST-like interactions - we use media-types (and of course the actually interesting content-format).

This is what this proposal does. It is in support of protocols to deal with Evidence and Attestation Results (beyond EAT! Please do not forget that there are billions of devices out there that create Evidence that is not EAT) to disambiguate Evidence and Attestation Results (because conflating them is very harmful) and to help simple protocols ind constrained environments to function in a secure manner.

Hence, I think it is a valuable and even necessary proposal. If you scope your requirements to the Entity Attestation Protocol or FIDO, I think you are correct, you do not need them.

I also think that this discussion might take up some time and therefore I very early indicated that we can deal with that in an upcoming media type I-D.

When we are writing up the media-types, what we - at minimum - have to establish is that we do not *contradict* the intended use of EAT, but rather *support* it.

Viele Grüße,

Henk

On 30.01.22 03:00, Giridhar Mandyam wrote:
> [1] 
> https://github.com/veraison/veraison/blob/7ebedb0bdf172345a272c954ef88
> 160581d79f6e/provisioning/api/handler.go#L94
> [2] 
> https://github.com/veraison/veraison/blob/7ebedb0bdf172345a272c954ef88
> 160581d79f6e/provisioning/plugins/corim-tpm-enacttrust-decoder/decoder
> .go#L9 [3] 
> https://github.com/veraison/veraison/blob/7ebedb0bdf172345a272c954ef88
> 160581d79f6e/provisioning/plugins/corim-psa-decoder/decoder.go#L9
>
> --
> Thomas
>

---

From: Thomas Fossati <[email-masked]>
Date: Sun, 30 Jan 2022 18:27:00 +0000

On Sun, Jan 30, 2022 at 5:30 PM Giridhar Mandyam
<[email-masked]> wrote:
> Should a verifier reject a valid EAT token if it is designated with the existing CWT/JWT media type rather than the future EAT media type? If so, why?

The question is ill posed.
A verifier that exposes an HTTP API gets to decide, among a bunch of
other things, which media types it accepts.
If, to consume EATs, it requires the client to say Content-Type:
application/cwt+cbor (or anything else, e.g.:
application/vnd.my-api.eat-stuff) it's purely its choice.  And
whatever it doesn't accept, it rejects with a 415 and the list of
supported types.
To interop the client can't just throw at some random web location an
application/cwt+cbor and hope it will work, it needs to know all the
details of the API it's using.  And while EAT doesn't define the API
(because there is obviously not going to be a single "EAT API"), it
can (should?) provide good building blocks.

> What is your expectation if and when an EAT specific media type is defined?

The proposal I'm putting forward is one that allows, if needed, to
provide a finer-grained and consistent type system to the (extensible)
class of EAT profiles.
I say consistent because the expectation is that, using the proposed
template, the "XYZ" EAT profile automatically gets a media type
derived from the base application/eat+cbor by populating the "profile"
parameter.

> Can you point to any reports from interop events where developers could simply not support an attestation protocol without the designation of a new media type?

No I can't, and I don't think that's the point.  We are not fixing an
existing interop problem here, we are designing an API building block
that can work across different use cases.

-- 
Thomas

---

From: Laurence Lundblade <[email-masked]>
Date: Sun, 30 Jan 2022 10:36:49 -0800

I’m hoping for  lots of use cases for EAT. Many won’t need a media type, but it seems reasonable to expect some will. Giri has given an example of FIDO that doesn’t and Thomas has given one example where it is helpful.

An EAT can be any of these:
- CWT
- JWT
- UCCS
- UJCS
- CBOR-encoded DEB (Detached EAT Bundle) 
- JSON-encoded DEB 

The salient characteristic that makes it an EAT is that it is made up of claims defined by EAT for the purpose of attestation. It’s not the encoding. It seems useful to be able to identify an EAT independent of the particular EAT encoding.

If you received something media-identified as EAT, you could figure out which of the above formats it is by sniffing the first few bytes, particular if CBOR tags are used.

This seems like a simple easy addition to EAT. The PR is simple. We generally know how to define media types. It’s been done many times before.

(and Thomas is doing work :-) )

LL

---

From: Michael Richardson <[email-masked]>
Date: Sun, 30 Jan 2022 14:08:43 -0500

Thomas Fossati <[email-masked]> wrote:
    >> Can you explain the use case here?  I don't understand how this would
    >> be used; it seems redundant.

    > as a routing signal inside your (RESTful) API stack.

I see.
With CoAP, you wind up with unique CF, I think.

---

From: Giridhar Mandyam <[email-masked]>
Date: Sun, 30 Jan 2022 19:14:07 +0000

There is clearly not consensus on this topic, an d whether this is a useful or even necessary addition to the EAT spec.  

I would suggest proponents take it to the WG and propose why an EAT media type is required, and be very specific as to when it is to be used in place of the existing CWT media type.  In the meantime, I have closed the issue because I have not determined from all the discussion why the existing media types are insufficient.

In the meantime, the issue can be kept open but no PR should be merged (in my opinion).

-Giri

-----Original Message-----
From: Laurence Lundblade <[email-masked]> 
Sent: Sunday, January 30, 2022 10:37 AM
To: Giridhar Mandyam <[email-masked]>; Henk Birkholz <[email-masked]>; [email-masked]
Cc: Thomas Fossati <[email-masked]>; Michael Richardson <[email-masked]>; Thomas Fossati <[email-masked]>
Subject: Re: [Rats] A media type for EAT

LL

---

From: Giridhar Mandyam <[email-masked]>
Date: Sun, 30 Jan 2022 19:15:54 +0000

Clarification:  I have *not* closed the issue.  But I do think this should not be a blocking issue to prevent EAT from moving to IESG LC.  Sorry for any confusion.

-----Original Message-----
From: RATS <[email-masked]> On Behalf Of Giridhar Mandyam
Sent: Sunday, January 30, 2022 11:14 AM
To: Laurence Lundblade <[email-masked]>; Henk Birkholz <[email-masked]>; [email-masked]
Cc: Michael Richardson <[email-masked]>; Thomas Fossati <[email-masked]>; Thomas Fossati <[email-masked]>
Subject: Re: [Rats] A media type for EAT

-Giri

-----Original Message-----
From: Laurence Lundblade <[email-masked]>
Sent: Sunday, January 30, 2022 10:37 AM
To: Giridhar Mandyam <[email-masked]>; Henk Birkholz <[email-masked]>; [email-masked]
Cc: Thomas Fossati <[email-masked]>; Michael Richardson <[email-masked]>; Thomas Fossati <[email-masked]>
Subject: Re: [Rats] A media type for EAT

LL

---

From: Giridhar Mandyam <[email-masked]>
Date: Sun, 30 Jan 2022 19:26:47 +0000

> The question is ill posed.

Really?  Some of us have to ensure interoperability between implementations from different vendors/sources.  If you don't want to answer then fine - but it still is something that should be addressed with existing implementations and interop programs.

> A verifier that exposes an HTTP API gets to decide, among a bunch of other things, which media types it accepts.

With the verifier you have in mind, are you saying that it won't accept media types with a CWT designation alone?  If so, I think you have an implementation issue that you are expecting the EAT spec to solve.

> The proposal I'm putting forward is one that allows, if needed, to provide a finer-grained and consistent type system to the (extensible) class of EAT profiles.
I say consistent because the expectation is that, using the proposed template, the "XYZ" EAT profile automatically gets a media type derived from the base application/eat+cbor by populating the "profile"
parameter.

You keep referring to application/eat+cbor but still have not provided a justification as to why application/cwt is insufficient to base your proposal.  It seems that the problem you are trying to solve results from a lack of expressiveness in the existing CWT/JWT media types - which is a broader topic than just eat.  For instance, is a different media type required for every CWT/JWT encapsulation?

-Giri

-----Original Message-----
From: Thomas Fossati <[email-masked]> 
Sent: Sunday, January 30, 2022 10:27 AM
To: Giridhar Mandyam <[email-masked]>
Cc: Michael Richardson <[email-masked]>; [email-masked]; Thomas Fossati <[email-masked]>
Subject: Re: [Rats] A media type for EAT

The question is ill posed.
A verifier that exposes an HTTP API gets to decide, among a bunch of other things, which media types it accepts.
If, to consume EATs, it requires the client to say Content-Type:
application/cwt+cbor (or anything else, e.g.:
application/vnd.my-api.eat-stuff) it's purely its choice.  And whatever it doesn't accept, it rejects with a 415 and the list of supported types.
To interop the client can't just throw at some random web location an application/cwt+cbor and hope it will work, it needs to know all the details of the API it's using.  And while EAT doesn't define the API (because there is obviously not going to be a single "EAT API"), it can (should?) provide good building blocks.

> What is your expectation if and when an EAT specific media type is defined?

The proposal I'm putting forward is one that allows, if needed, to provide a finer-grained and consistent type system to the (extensible) class of EAT profiles.
I say consistent because the expectation is that, using the proposed template, the "XYZ" EAT profile automatically gets a media type derived from the base application/eat+cbor by populating the "profile"
parameter.

> Can you point to any reports from interop events where developers could simply not support an attestation protocol without the designation of a new media type?

No I can't, and I don't think that's the point.  We are not fixing an existing interop problem here, we are designing an API building block that can work across different use cases.

--
Thomas

---

From: Anders Rundgren <[email-masked]>
Date: Sun, 30 Jan 2022 20:31:42 +0100

+1

On Sun, Jan 30, 2022, 20:27 Giridhar Mandyam <[email-masked]>
wrote:

> >> Should a verifier reject a valid EAT token if it is designated with the
> existing CWT/JWT media type rather than the future EAT media type? If so,
> why?
>
> Really?  Some of us have to ensure interoperability between
> implementations from different vendors/sources.  If you don't want to
> answer then fine - but it still is something that should be addressed with
> existing implementations and interop programs.
>
> With the verifier you have in mind, are you saying that it won't accept
> media types with a CWT designation alone?  If so, I think you have an
> implementation issue that you are expecting the EAT spec to solve.
>
> template, the "XYZ" EAT profile automatically gets a media type derived
> from the base application/eat+cbor by populating the "profile"
> parameter.
>
> You keep referring to application/eat+cbor but still have not provided a
> justification as to why application/cwt is insufficient to base your
> proposal.  It seems that the problem you are trying to solve results from a
> lack of expressiveness in the existing CWT/JWT media types - which is a
> broader topic than just eat.  For instance, is a different media type
> required for every CWT/JWT encapsulation?
>
> -Giri
>
> WARNING: This email originated from outside of Qualcomm. Please be wary of
> any links or attachments, and do not enable macros.
>
> > Should a verifier reject a valid EAT token if it is designated with the
> existing CWT/JWT media type rather than the future EAT media type? If so,
> why?
>
> application/vnd.my-api.eat-stuff) it's purely its choice.  And whatever it
> doesn't accept, it rejects with a 415 and the list of supported types.
> (because there is obviously not going to be a single "EAT API"), it can
> (should?) provide good building blocks.
>
> The proposal I'm putting forward is one that allows, if needed, to provide
> a finer-grained and consistent type system to the (extensible) class of EAT
> profiles.
> template, the "XYZ" EAT profile automatically gets a media type derived
> from the base application/eat+cbor by populating the "profile"
> parameter.
>
> > Can you point to any reports from interop events where developers could
> simply not support an attestation protocol without the designation of a new
> media type?
>
> existing interop problem here, we are designing an API building block that
> can work across different use cases.
>
> > -Giri
> >
> > WARNING: This email originated from outside of Qualcomm. Please be wary
> of any links or attachments, and do not enable macros.
> >
> > hi Giri,
> >
> > > The introductory section of EAT clearly states that EAT can be a CWT
> or a JWT.  Both of these two data types already have corresponding media
> type registrations (
> https://datatracker.ietf.org/doc/html/rfc8392#section-9.2 and
> https://datatracker.ietf.org/doc/html/rfc7519#section-10.3,
> respectively).  I don't know why the existing media types are not
> sufficient, and nothing in the discussion below provides any insight to me
> either as to why another media type is required.
> >
> > From the point of view of a Verifier that exposes a single API endpoint
> to support different attestation formats (including multiple EAT profiles),
> one wants to rely on standard HTTP/CoAP content negotiation rather than
> resorting to MIME sniffing in order to dispatch the incoming request to the
> right processor.  In that context having a single application/cwt+cbor for
> everything EAT is less than ideal, you need a more expressive type system.
> >
> > cheers,
> > --
> > Thomas
>
>
>
> --
> Thomas

---

From: Giridhar Mandyam <[email-masked]>
Date: Sun, 30 Jan 2022 19:34:10 +0000

I will drop out of this thread as this is becoming a personal attack.  I don’t see why my questions are wrong in someway and should be ridiculed.

From: Anders Rundgren <[email-masked]>
Sent: Sunday, January 30, 2022 11:32 AM
To: Giridhar Mandyam <[email-masked]>
Cc: Thomas Fossati <[email-masked]>; Michael Richardson <[email-masked]>; Thomas Fossati <[email-masked]>; [email-masked]
Subject: Re: [Rats] A media type for EAT

-Giri

-----Original Message-----
From: Thomas Fossati <[email-masked]<mailto:[email-masked]>>
Sent: Sunday, January 30, 2022 10:27 AM
To: Giridhar Mandyam <[email-masked]<mailto:[email-masked]>>
Cc: Michael Richardson <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Thomas Fossati <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rats] A media type for EAT

> From: Thomas Fossati <[email-masked]<mailto:[email-masked]>>
> To: Giridhar Mandyam <[email-masked]<mailto:[email-masked]>>
> Cc: Michael Richardson <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Thomas
> Fossati <[email-masked]<mailto:[email-masked]>>
> On Sun, Jan 30, 2022 at 2:00 AM Giridhar Mandyam <[email-masked]<mailto:[email-masked]>> wrote:

--
Thomas
_______________________________________________
RATS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rats

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 31 Jan 2022 09:18:21 +0100

Hi EATers,

May I put some historic facts on the table?

20 years ago when the WS* was at its prime, media types were not used to separate object types and it worked pretty well.

Nowadays, tons of systems out there use the media type "application/json" where the only common denominator is that the data is JSON-formatted.

This seems to work fine, but most of these systems are based on a unique endpoint for each unique object type and operation.

What EAT apparently wants to do is pushing different EAT objects types through a single end-point, right?

Although parameterized media-types of course work, this would IMO be an unfortunate path for a standard, because the other and probably more established method (tagging each object-type with a unique identifier), preserves this property even after it has been received.

There were never really any need for specific JOSE or COSE media types either, but I [sort of] understand if the authors' thought differently :)

Personally, I put a unique object type like a URL on every object intended for external consumption [*].  The only problem is agreeing on a common key, otherwise this concept isn't particularly useful.

Thanks,
Anders

*] https://github.com/fido-web-pay/specification/issues/5

---

From: Michael Richardson <[email-masked]>
Date: Mon, 31 Jan 2022 09:45:44 -0500

I hope that I get the quoting right.  I am editing the message to show who
said what.
It would be significantly easier for everyone is people didn't top-quote, and
didn't use HTML.  (The archives don't keep your HTML)
The Usenet quoting conventions from the 1980s WORK. Use them.
Even Outlook can be taught to do it right.
Not using them results in people being upset because they can't understand
who said what, and then feeling like there are personal attacks.

Giridhar Mandyam <[email-masked]> is "giri>"
Anders Rundgren <[email-masked]. is "anders>"

    giri> Really?  Some of us have to ensure interoperability between
    giri> implementations from different vendors/sources.  If you don't want to
    giri> answer then fine - but it still is something that should be addressed
    giri> with existing implementations and interop programs.

    anders> A verifier that exposes an HTTP API gets to decide, among a bunch
    anders> of other things, which media types it accepts.

    giri> With the verifier you have in mind, are you saying that it won't accept
    giri> media types with a CWT designation alone?  If so, I think you have an
    giri> implementation issue that you are expecting the EAT spec to solve.

    anders> The proposal I'm putting forward is one that allows, if needed, to
    anders> provide a finer-grained and consistent type system to the (extensible)
    anders> class of EAT profiles.

    giri> I say consistent because the expectation is that, using the proposed
    giri> template, the "XYZ" EAT profile automatically gets a media type derived
    giri> from the base application/eat+cbor by populating the "profile"
    giri> parameter.

    giri> You keep referring to application/eat+cbor but still have not provided
    giri> a justification as to why application/cwt is insufficient to base your
    giri> proposal.  It seems that the problem you are trying to solve results
    giri> from a lack of expressiveness in the existing CWT/JWT media types -
    giri> which is a broader topic than just eat.  For instance, is a different
    giri> media type required for every CWT/JWT encapsulation?

application/cwt is no more wrong than application/octet-stream is when the
context is text/html.

More precise media types allow for more control and better interoperability
as we evolve specifications.

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 31 Jan 2022 15:58:10 +0100

To simplify things a bit, I'm with Giri.

That is, "application/cwt" is entirely sufficient for all objects expressed as CWTs

In addition, I claim EAT objects MUST be fitted with a unique identifier using
a registered key in similarity to "aud" etc.

That's all :)

Anders

---

From: Thomas Fossati <[email-masked]>
Date: Mon, 31 Jan 2022 17:53:42 +0000

> I hope that I get the quoting right.  I am editing the message to show who

Thanks Michael -- though you actually got the quoting wrong ;-)

To get the right attribution you need to s/anders/thomas/g and
s/giri/thomas/ in one instance.  (I have provided the fixes in-line.)

> Thomas Fossati <[email-masked] is "thomas>"
>
>     thomas> A verifier that exposes an HTTP API gets to decide, among a bunch
>     thomas> of other things, which media types it accepts.

>     thomas> The proposal I'm putting forward is one that allows, if needed, to
>     thomas> provide a finer-grained and consistent type system to the (extensible)
>     thomas> class of EAT profiles.

>     thomas> I say consistent because the expectation is that, using the proposed
>     thomas> template, the "XYZ" EAT profile automatically gets a media type derived
>     thomas> from the base application/eat+cbor by populating the "profile"
>     thomas> parameter.

>     giri> media type required for every CWT/JWT encapsulation?

and apologies if any of my words have been perceived as hostile, which
obviously wasn't my intention.

+1

I will withdraw the PR.  We can deal with this feature in a separate document.

cheers,
-- 
Thomas