Re: [Rats] IANA pre-RFC code points

[Thomas Fossati <[e-mail]>]

On 16/02/2021, 20:25, "Laurence Lundblade" <[e-mail]> wrote:
> Below...
>
> > On Feb 16, 2021, at 11:10 AM, <[e-mail]> wrote:
> >
> > On 16/02/2021, 17:43, <[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?

I like OIDs because they are relatively compact and unambiguous. They
look like the CBOR-friendly equivalent of URIs.  They also render well
in JSON as strings in dotted notation.

What is not clear to me at the moment is what kind of benefit we get
from allowing unstructured text?  And if there is a benefit, what
strategy do we want to recommend to avoid collisions?

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

Yes, that'd be my preference: namespaced types only.

> 4) Just a text string.
> My preference is 1) since it is in use for other things.

See above.

> 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.

+1

Cheers!





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.