Subject: [Rats] Identity topic - was RATS rechartering poll

From: "Smith, Ned" <[email-masked]>
Date: Thu, 3 Mar 2022 23:05:03 +0000

This thread seems to have diverged from its original purpose to collect yes/no votes.
Please use a different subject name.
Thx,
Ned

From: RATS <[email-masked]> on behalf of Laurence Lundblade <[email-masked]>
Date: Wednesday, March 2, 2022 at 11:26 PM
To: Thomas Fossati <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Smith, Ned" <[email-masked]>
Subject: Re: [Rats] RATS rechartering poll

I’d like to drive a big distinction between Verifier Identity and Attester/Device Identity. They are both critical, but very different.

Verifier Identity
This seems like common B2B TLS set up and security. IT people do this all the time.

In the protocol implementation, the Verifier Identifier is usually a DNS name. In the business arrangement between Verifier and RP there is probably a contract (which may be a click-through) that says what verification process the Verifier runs and describes what sort of security it implements and checks. This is super important, but the business agreement is out of scope for RATS.

Verifier Identity could also be implemented with JWT, CWT or EAT, in which case it might be a little different. Probably similar to how JWT’s are used for authentication.

Many of these B2B sets ups are high security. Think about the implementation of an online brokerage or bank. They are dealing with value and risk at least as attestation in many cases.

I don’t think there’s much work here for RATS to design or define here. We just need some security considerations.

Attester/Device Identity
Here we’ve got lots of work to do here (and we’ve done much of it)

This can be in several forms all of which may be in the Evidence at the same time
 - Identification by serial number (UEID/SUED in EAT)
 - Identification of OEM and model
 - Identification of the Attester (this is roughly equivalent to identification of the verification key)

There might be several Attester/Device Identities in composite devices.

Work here is getting people to understand what attestation is, how the keys work, defining formats and protocols for identity and so on.

An RP of course must always care about Verifier Identity.

An RP may or may not care about Attester/Device Identity. It’s entirely reasonable for an RP to want only a yeah/nay for a device and it’s entirely reasonable to want all the Attester/Device Identity it can have or something in between.

The Attester/Device Identity might come from the actual attester/device in Evidence, but the Verifier might be the one to figure out it and provide it to the RP. For example, the Verifier might only receive the Attester identifier, a unique key ID, one for each device and from that figure out the serial number, OEM and model and send that on to the RP.

I’d like to see ar4si be sharp in this distinction, like separating the discussion of these two into separate sections in the document.

Comments below,

On Mar 1, 2022, at 4:41 AM, Thomas Fossati <[email-masked]<mailto:[email-masked]>> wrote:

Hi Laurence,

On Sun, Feb 27, 2022 at 11:21 PM Laurence Lundblade
<[email-masked]<mailto:[email-masked]>> wrote:

I think providing authenticated integrity-protected device identity (make, model, serial number) all the way to the RP is part of RATS and the RATS standards should cover it in full standardized detail. (This is akin to providing a user name in authentication protocols and the server identifier in TLS).

I agree with you that identity is fundamental in trust establishment.
At the end of the day an evidence claim is a sentence of the form:
"attester says blah" and the precondition for evaluating the
trustworthiness of any such claim is to first determine the identity
of the claimant.

Also, I agree that in many cases the identity of the attester can
percolate through the attestation results to the RP where it will be
used either as an input to the local appraisal policy or passed to a
higher layer protocol.

However, the quantum of attester identity that reaches the RP depends
on the functional split between Verifier and RP.  One can envisage
situations where that quantum amounts to a simple attestation results'
claim from the Verifier that just says "attester recognised and good!"
-- maybe because of the overall privacy policy, or because the RP is
an extremely basic one, or because the RP doesn't care about the
identity details.

So, I am not sure I agree with the "[...]  all the way to the RP" part
of your sentence.  Instead, an identity that the RP needs to consider
*in all cases* is the identity of the Verifier.

It's maybe worth looking at Section 2.2 of AR4SI where all of this is
discussed in depth.

I looked at it and came up with the above comments.

I think we mostly agree. :-)

I certainly agree that the quantum of attester/device identity reaching the RP will vary and sometimes not go to the RP at all.

Then to clarify what I’m request — I requesting that *when attester/device identity goes to the RP* it is in a RATS standard format.

[...]
I think this goes far enough beyond attester’s trustworthiness to warrant the additional text about authenticated claims.

ISTM that we could achieve what you are asking (and more) by allowing
evidence to be encapsulated into (or otherwise bound to) the
authenticated attestation results, so that even in passport mode it'd
be fully visible to the RP?

Seems like a pretty interesting idea! Will think about it!

I don’t think it covers the case where the Verifier figures out some of the device identity claims in results based on attester/device identity it got in evidence, but it still seems useful.

LL