Re: [Rats] UEID where an instance is a group member

Hi Laurence,

potentially, I just realized, it could serve the purpose of matching the 
Authenticator Moodel of a FIDO Authenticator and therefore might help 
the peer that the Atttester is talking to understand the format it has 
to expect being incoming based on the additional input of a FIDO 
Metadata-Service (aka the Authentcator-Model that is called, IIRC?). Any 
structure of that kind would help a Verifier to better... "guess" 
(well.. it probably is the output of some kind of negotiation), whether 
it is, e.g. FIDO or RIV?

Viele Grüße,

Henk

On 25.03.20 17:46, Laurence Lundblade wrote:
> A GEID of similar structure to a UEID  seems like a possibility, but 
> what exactly is purpose of such a GEID? What does the RP do with it? 
> What does the verifier do with it?
> 
> An RP will use the UEID to track the unique, specific device. That is 
> its clearly stated purpose.
> 
> In some designs, a verifier may use the UEID to identify the 
> verification key, but that is not the UEID’s purpose. It a useful 
> side-effect.
> 
> If the purpose of a GEID is solely for the verifier to identify the 
> verification key, then I don’t think it is should be a GEID. It should 
> be key id.
> 
> So for me this kind of hinges on what a GEID will mean for the RP. What 
> are the groupings it gives and how are they meaningful to an RP?
> 
> LL
> 
> 
> 
>> On Mar 25, 2020, at 9:29 AM, Smith, Ned <ned.smith@intel.com 
>> <mailto:ned.smith@intel.com>> wrote:
>>
>> Is a GEID structurally different from a EUID? I think currently a EUID 
>> is either a 128-bit or 256-bit bstr. I assume the semantics of 
>> uniqueness differ.
>> *From:*RATS <rats-bounces@ietf.org <mailto:rats-bounces@ietf.org>> on 
>> behalf of Simon Frost <Simon.Frost@arm.com <mailto:Simon.Frost@arm.com>>
>> *Date:*Wednesday, March 25, 2020 at 8:47 AM
>> *To:*Laurence Lundblade <lgl@island-resort.com 
>> <mailto:lgl@island-resort.com>>, "rats@ietf.org 
>> <mailto:rats@ietf.org>" <rats@ietf.org <mailto:rats@ietf.org>>
>> *Subject:*[Rats] UEID where an instance is a group member
>> We had an internal discussion in response to some changes in PSA which 
>> have elaborated the definition of an Instance Attestation Key (IAK) so 
>> that it may either be “unique to each device or a collection of 
>> identical devices”. The definition of the Identity claim is now a 
>> value that identifies the IAK. This has been done to support entity 
>> grouping for (some) privacy scenarios.
>> While we have an EAT Profile for PSA that uses a full set of custom 
>> claims, our intent has always been to be to migrate as many claims as 
>> possible to the standard once the RATS work is complete. Previously, 
>> there has been a direct analogy betweenarm_psa_UEIDand the standard 
>> UEID. With this change though, we would have to move away from this. 
>> The current description of UEID makes it clear that it must be device 
>> world unique. There is some discussion 
>> (https://ietf-rats-wg.github.io/eat/draft-ietf-rats-eat.html#name-ueid-privacy-considerations) 
>> of the group scenario, but the only statement about the claim 
>> situation is that “It will often be the case that tokens will not have 
>> a UEID for these reasons”.
>> In the privacy scenario, it is still desirable to have an entity 
>> identity claim, for use by a verifier or for general usage. The 
>> options seem to be:
>> a/ If the entity is unique, include an UEID claim, otherwise include a 
>> custom group claim. It seems a pity to encourage diversification 
>> between profiles.
>> b/ If the entity is unique, include an UEID claim, otherwise use a new 
>> standard GEID claim
>> c/ punt this problem out to the kid of the COSE wrapper. This would 
>> ignore any more general uses of group identities.
>> Of these, b/ (introduce a new standard GEID claim) seems to make the 
>> most sense and is the option we would propose to the WG.
>> Thoughts?
>> Thanks
>> Simon
>> Simon Frost
>> Senior Principal Systems Solution Architect, ATG, Arm
>> Mob: +44 7855 265691
>> 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
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats
> 