Subject: [Rats] Primordial verifier types

From: Laurence Lundblade <[email-masked]>
Date: Fri, 11 Feb 2022 13:07:48 -0800

This is to level-up the security-level discussion. This is some modeling for what Verifiers do and the results they produce.

This only models primordial types. Real Verifiers will be somewhere between these archetypes. 

I don’t think there is any right or wrong here. EAT should roughly support all. 

ar4si implies one way to build a Verifier, a particular sort that is close to a strong evaluator.

• Evidence passthrough verifiers mostly just verify the signature using the public key in the Endorsement. The real work is done by the relying party. Perhaps it has a machine learning risk engine.
• Endorsement passthrough verifiers look up the device by make and model in evidence to find all the claims to put in the results. Again the real work is done by the relying party.
• Strong evaluator verifiers do most of the work and produce a simple result, possibly as simple as pass/fail.
• Transformer Verifiers do a lot of work that changes the form of the input claims to something more suitable for particular relying parties.
• Many combinations are possible:
	• A strong evaluator may only get identity evidence
	• A strong evaluator may also pass through all of the endorsement and all of the evidence along side the summary result
	• A transformer may only get identity, and do a lot of rearranging of claims in the endorsement

LL

---

From: Henk Birkholz <[email-masked]>
Date: Sat, 12 Feb 2022 00:30:50 +0100

Hi Laurence,

I really appreciate your efforts and I get the points you are making 
here. Alas, I am now afraid that EAT might have contracted a bit of a 
feature creep:

* there are other bodies that depend on EAT strongly (as Giri and Jeremy 
have pointed out on multiple occasions)
* I am under the uncanny impression that there is no consensus amongst 
the editors wrt to the semantics of some of the Claims (apparently the 
most prominent example is 'security-level')
* there seems to be a stark contrast between the abstract summarizing 
what EAT should do and what it is actually trying to do today

In an effort to try to err on the side of caution, I'd like to carefully 
recommend the following actions:

* revisit the state of -09 and try to split off a stable EAT core that 
can be moved forward to iesg OR a at least freeze and progress a state 
that reflects the early allocation list (without security-level)
* move EAT to IESG ASAP based on that simplified core
* create a set of requirements that justify the inclusion of Claims 
beyond that initial core in a fashion similar to RFC9124
* build and split off additional incremental I-Ds based on these 
requirements

Viele Grüße,

Henk

On 11.02.22 22:07, Laurence Lundblade wrote:
> This is to level-up the security-level discussion. This is some modeling 
> for what Verifiers do and the results they produce.
> 
> • Evidence passthrough verifiers mostly just verify the signature using 
> the public key in the Endorsement. The real work is done by the relying 
> party. Perhaps it has a machine learning risk engine.
> • Endorsement passthrough verifiers look up the device by make and model 
> in evidence to find all the claims to put in the results. Again the real 
> work is done by the relying party.
> • Transformer Verifiers do a lot of work that changes the form of the 
> input claims to something more suitable for particular relying parties.
> • A strong evaluator may also pass through all of the endorsement and 
> all of the evidence along side the summary result
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 14 Feb 2022 11:58:13 -0800

Hey Henk,

The only work left on EAT is minor:
   Update to be compatible UCCS-02. This is primarily CDDL work and not any new semantics. (For those of you that might not have read it, UCCS-02 now has CDDL for JSON-encoded claims)
   Maybe remove a claim or two for which there isn’t consensus

My email on Verifier types is not a proposal for any new work of any sort.

> On Feb 11, 2022, at 3:30 PM, Henk Birkholz <[email-masked]> wrote:
> 
> * I am under the uncanny impression that there is no consensus amongst the editors wrt to the semantics of some of the Claims (apparently the most prominent example is 'security-level’)

There is rough consensus on security-level among the EAT authors. Not perfect, but rough.

LL

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 14 Feb 2022 21:06:14 +0100

On 2022-02-14 20:58, Laurence Lundblade wrote:
>   *    Update to be compatible UCCS-02. This is primarily CDDL work and not any new semantics. (For those of you that might not have read it, UCCS-02 now has CDDL for JSON-encoded claims)
>   *    Maybe remove a claim or two for which there isn’t consensus
>

Well, the media type issue remains unsolved.  Profile name is also a strange thing to put inside of a claim set.

AR

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 14 Feb 2022 12:17:37 -0800

Hi Anders,

> On Feb 14, 2022, at 12:06 PM, Anders Rundgren <[email-masked]> wrote:
> 

I think profile is very different from media type. Media type is to dispatch / hand-off a token to the right handler.  Profile is roughly a reference policy and rules against which the claims should be interpreted. 

I’m personally neutral on the need for media type, but more importantly do not want to take on any more work in EAT to get it to last call, so I’m avoiding media type unless there some consensus that we need it.

LL

---

From: Ira McDonald <[email-masked]>
Date: Mon, 14 Feb 2022 15:20:58 -0500

Hi,

I agree with Laurence that we should avoid any media-type in EAT claims for
this first edition of the document.

Cheers,
- Ira

*Ira McDonald (Musician / Software Architect)*

*Chair - SAE Trust Anchors and Authentication TF*
*Co-Chair - TCG Trusted Mobility Solutions WG*

*Co-Chair - TCG Metadata Access Protocol SG*

*Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer
Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF
Designated Expert - IPP & Printer MIBBlue Roof Music / High North
Inchttp://sites.google.com/site/blueroofmusic
<http://sites.google.com/site/blueroofmusic>http://sites.google.com/site/highnorthinc
<http://sites.google.com/site/highnorthinc>mailto: [email-masked]
<[email-masked]>(permanent) PO Box 221  Grand Marais, MI 49839
906-494-2434*

On Mon, Feb 14, 2022 at 3:17 PM Laurence Lundblade <[email-masked]>
wrote:

> Well, the media type issue remains unsolved.  Profile name is also a
> strange thing to put inside of a claim set.
>
>
> I think profile is very different from media type. Media type is to
> dispatch / hand-off a token to the right handler.  Profile is roughly a
> reference policy and rules against which the claims should be interpreted.
>
> I’m personally neutral on the need for media type, but more importantly do
> not want to take on any more work in EAT to get it to last call, so I’m
> avoiding media type unless there some consensus that we need it.
>
> LL
>
>

---

From: Giridhar Mandyam <[email-masked]>
Date: Mon, 14 Feb 2022 20:41:20 +0000

> Media type is to dispatch / hand-off a token to the right handler.

And media type can be used by intermediaries to filter data types (like many firewalls annoyingly do), which is why we should be clear as to why we would need to specifically identify an EAT and profile in the Content Type field.  The token cannot get to the right handler if the token itself is blocked by in transit.

-Giri

From: RATS <[email-masked]> On Behalf Of Laurence Lundblade
Sent: Monday, February 14, 2022 12:18 PM
To: Anders Rundgren <[email-masked]>
Cc: rats <[email-masked]>; Henk Birkholz <[email-masked]>
Subject: [Rats] Profile Claim (was Re: Primordial verifier types)

Hi Anders,

On Feb 14, 2022, at 12:06 PM, Anders Rundgren <[email-masked]<mailto:[email-masked]>> wrote:

LL

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 15 Feb 2022 05:49:17 +0100

On 2022-02-14 21:17, Laurence Lundblade wrote:
> Hi Anders,
> 
>> On Feb 14, 2022, at 12:06 PM, Anders Rundgren <[email-masked] <mailto:[email-masked]>> wrote:
>>
> I think profile is very different from media type. Media type is to dispatch / hand-off a token to the right handler.

At least two prominent members members of the EAT club have suggested that EAT needs a more extensive solution like parameterized media types.  I would be cautious progressing the specification without having addressed this in more detail.  There is also a documented alternative which:
- has plenty of predecessors
- permits EAT object embedding

https://github.com/ietf-rats-wg/eat/issues/165

> Profile is roughly a reference policy and rules against which the claims should be interpreted.

I doubt many people understand the difference between media type as a selector and a profile.  Is the profile rather for human consumption?

Anders