Re: [Rats] IANA pre-RFC code points

[Laurence Lundblade <[e-mail]>]

Below...

> On Feb 16, 2021, at 11:10 AM, Thomas Fossati <[e-mail]> wrote:
> 
> On 16/02/2021, 17:43, "Laurence Lundblade" <[e-mail]> wrote:
>> 
>> If we can agree that profiles are necessary and that a simple text
>> string is good enough to name a profile, then we can put in in the
>> pre-allocation.  We don't have to agree on the mechanism for defining
>> profiles, just for naming them.
> 
> I think what is in -08 in terms of defining a profile is great.
> 
> I think we should just nail down the type and constraints around the
> claim value.  The way it is now (i.e., plain, unstructured tstr) creates
> an incentive to using short strings and therefore increasing the chance
> of collisions, which is bad.
> 
> If we say:
> ~~~
>  profile-claim = (
>    profile => $profile-type,
>  )
> 
>  $profile-type /= uri ; i.e., #6.32(tstr)
>  $profile-type /= oid ; draft-ietf-cbor-tags-oid
> ~~~
> 
> We'd allow both human readable https://fidoalliance.org/profile/a, as
> well as compact, machine readable 1.3.6.1.4.1.etc in a way that prevents
> clashes.
> 
> I don't think it's crazy to expect the profile owner to also control a
> DNS name and/or a PEN.

Yes, I was thinking we might want this to be a URI or such myself. Here’s several options:

1) Make it string-or-uri like the JWT issuer, subject and audience claims. Already well-established approach.

2) Allow string, URI or OID. Most flexibility, but do we really need OIDs?

3) URI or OID. No text string. Is that what you are proposing above? 

4) Just a text string.

My preference is 1) since it is in use for other things.

We don’t have to resolve details of the 12 things suggested for a profile for pre-allocation, but we do have to resolve the data type and generally agree on what profiles are.

LL