Subject: Re: [OAUTH-WG] FW: Appsdir review of draft-ietf-oauth-v2-23

From: Eran Hammer <[email-masked]>
Date: Wed, 7 Mar 2012 16:42:50 -0700

> -----Original Message-----
> From: Henry S. Thompson [mailto:[email-masked]]
> Sent: Tuesday, February 14, 2012 9:07 AM

> >> 11  It seems at best old-fashioned that the designer of a new access
> >> token type, parameter, endpoint response type or extension error has
> >> no better tool available than Google to help him/her discover whether
> >> the name they have in mind is in use already.  The same is true under
> >> the proposed approach for any developer trying to determine what they
> >> can use or must support.  Is there some reason that mandated URI
> >> templates, after the fashion of
> 
> >>   http://www.iana.org/assignments/media-types/text/
> 
> >> are not mandated for the registries, e.g.
> 
> >>   http://www.iana.org/assignments/access-token-types/bearer
> 
> >> ?  If there is a good reason, please use it to at least explicitly
> >> acknowledge and justify the basis for failing to provide a way for
> >> users and developers to use the &quot;follow your nose&quot; strategy
> >> [1].  If there is no good reason, please include the appropriate
> >> language to require something along the lines suggested above.  If
> >> you need a model, see [2].
> 
> > I'm confused - is this a request to use a full URI for all extension
> > values? I thought the purpose of a registry was to deconflict the
> > short names, and that URIs could be used for anything else.
> 
> No, I appreciate that you want to use registered short names in the protocol,
> that's just fine.  My problem is that you have left users, developers etc. with
> no way to discover what shortnames have been registered short of a non-
> trivial and error-prone informal search effort.
> 
> What I'm asking for is support for probe URI prefixes for each family of
> shortnames.  So, just as today I use "text/n3" as the media type for my
> Notation3 documents, I can check that this is a registered media type by
> attempting to retrieve
> 
>  http://www.iana.org/assignments/media-types/text/n3
> 
> and I can see all the registered text types by retrieving from
> 
>  http://www.iana.org/assignments/media-types/text
> 
> likewise I ought to be able to check e.g. the "bearer" token type by
> attempting retrieval from (something along the lines of)
> 
>  http://www.iana.org/assignments/access-token-types/bearer
> 
> and I should be able to see all the registered token types by retrieving from
> 
>  http://www.iana.org/assignments/access-token-types
> 
> Hope this clarifies what I meant.
> 

Not sure I understand what you are asking for, but what would the IANA instruction include to support this?

EH

---

From: Barry Leiba <[email-masked]>
Date: Wed, 7 Mar 2012 18:53:37 -0500

Henry says...
>> Hope this clarifies what I meant.

Eran says...
> Not sure I understand what you are asking for, but what would the IANA instruction include to support this?

Yeh, I'm not understanding this either.  The spec establishes an
access-token-type registry, and anyone will be able to look in that
registry the same way they look in any other IANA registry, such as
media-types.  It looks like Henry is asking for this to use some sort
of type/subtype mechanism, as media-types does, wherein when a new
token type is registered, that registration or subsequent ones can
create subtypes of that token type.

But it's not clear that such a type/subtype scheme would always apply
here, as it does with media types.  Some token types will have no
subtypes.  What makes more sense is for the token types that need to
create their own sub-registries to do so.  And then those entries will
be found from IANA as well -- no error-prone informal search effort
should be needed.

Or am I missing the same thing Eran is?

Barry

---

From: [email-masked] (Henry S. Thompson)
Date: Thu, 08 Mar 2012 11:44:39 +0000

Barry Leiba <[email-masked]> writes:

> Henry says...
>>> No, I appreciate that you want to use registered short names in
>>> the protocol, that's just fine.  My problem is that you have left
>>> users, developers etc. with no way to discover what shortnames
>>> have been registered short of a non- trivial and error-prone
>>> informal search effort.
>>> . . .
>
> Eran says...
>> Not sure I understand what you are asking for, but what would the
>> IANA instruction include to support this?
>

No, sorry, not at all about subtyping or anyting like that.

Sorry this is proving difficult to communicate!

Start again.  Consider the situation five years from now, when OAUTH2
is a great success, and there are dozens of entries in its various
registries.

 1) Suppose you're a developer, setting out to implement OAUTH2.  You
    need to know what access token types, etc. to implement;

 2) Or you're a user, wondering what access token types are available,
    so you can decide which suit your requirements best;

 3) Or you're a service provider, and you come up with a new token
    type and want to check if the name you have in mind is already in
    use.

You have read the spec., and the _only_ concrete thing it tells you
about the registers is the name of an email list.  So you have to go
to the email archives and search for . . . what exactly?  Different in
the three cases above, and in none of them is it obvious how to know
what counts as success.

So what I'm asking for is more mechanism, documented in the spec. in
terms of what the registry itself will provide, which is, in each
case, a URI which will not only resolve to a list of the registered
shortnames, but will also support retrieval for any registered short
name by appending it.  So for example for the access token type
registry, the spec. should tell me that retrieving

  http://www.iana.org/oath2/access-token-types

will give me a page listing all the registered access token types, and
also

    http://www.iana.org/oath2/access-token-types/bearer

will return the registration details for the bearer type.

This will then make all of (1)--(3) easy.

Better this time?

ht
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: [email-masked]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

---

From: Barry Leiba <[email-masked]>
Date: Thu, 8 Mar 2012 09:50:29 -0500

> the three cases above, and in none of them is it obvious how to know

The email list is just how you start the registration process.  There
will be an IANA registry for access token types.  When IANA creates
it, the name will be in the published RFC (I expect there'll be a
section in the IANA registries page ( http://www.iana.org/protocols/ )
for "OAuth Parameters", and "Access Token Types" will be listed there;
search that page for "DKIM" to see what it'll look like).  The spec
also says what will be *in* the registry.

The RFC Editor specifically does NOT want the URL for the registry to
be in the RFC (the URL might change).  But the registry NAME will be
there.

Barry

---

From: [email-masked] (Henry S. Thompson)
Date: Thu, 08 Mar 2012 15:05:05 +0000

> be in the RFC (the URL might change).  But the registry NAME will be

OK, I now recognise a culture clash as the underlying point at issue,
so this spec. is the wrong place to address it.

Thanks for your patience, I hereby get out of the road on this point.

I'll reply to Eran's message wrt any other outstanding points. . .

ht

---

From: Barry Leiba <[email-masked]>
Date: Thu, 8 Mar 2012 10:10:07 -0500

> so this spec. is the wrong place to address it.

Ah... so if the issue is how IANA makes registry information
available, then please go to the "happiana" mailing list (
https://www.ietf.org/mailman/listinfo/happiana ) and see if you can
work with Michelle and the other IANA folks on it.

Barry

---

From: [email-masked] (Henry S. Thompson)
Date: Thu, 08 Mar 2012 15:13:12 +0000

Barry Leiba writes:

> available

Precisely.

> then please go to the "happiana" mailing list (

Indeed.  I should have realised that that was the right level sooner:
as I said, thanks for your patience.

ht

---

From: Derek Atkins <[email-masked]>
Date: Wed, 21 Mar 2012 15:15:21 -0400

> as I said, thanks for your patience.

If you need help coordinating with Michelle @ IANA I can help coordinate
a meeting in Paris next week (assuming you are attending).

> ht

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant