I think registration_access_url is OK.    I haven't heard any better names yet.

John B.
On 2013-02-20, at 1:04 PM, Mike Jones <[email protected]> wrote:

> For what it’s worth, the name “registration_access_url” was chosen to be 
> parallel to “registration_access_token”.   It’s the place you use the access 
> token.  And it’s where you access an existing registration.  I’m against the 
> name “client_metadata_url” because it’s not metadata you’re accessing – it’s 
> a registration you’re accessing.  For the same reason, I don’t think the name 
> “client_info_url” gives people the right idea, because it doesn’t say 
> anything it being the registration that you’re accessing.
>  
> If you really want us to change this, having read what’s above, I could live 
> with “client_registration_url”, but I don’t think a change is actually 
> necessary.  (But if we are going to change it, let’s do it ASAP, before the 
> OpenID Connect Implementer’s Drafts are published.)
>  
>                                                             -- Mike
>  
> From: [email protected] [mailto:[email protected]] On Behalf Of Nat 
> Sakimura
> Sent: Wednesday, February 20, 2013 7:58 AM
> To: <[email protected]>; Richer, Justin P.; John Bradley
> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
>  
> Thanks Justin.
> 
> Even if we go flat rather than doing JSON Structure, the "Client
> Registration Access Endpoint" is not a good representative name.
> 
> What it represents is the client metadata/info.
> It is not representing "Client Registration Access". 
> What does "Client Registration Access" mean? 
> Does UPDATing "Cleint Registration Access" make sense?
> 
> Something in the line of "Client Metadata Endpoint" and
> something like "client_metadata_url" or "client_info_url" is much better.
> 
> Nat
> 
> 2013/2/15 Richer, Justin P. <[email protected]>
> Everyone, there's a new draft of DynReg up on the tracker. This draft tries 
> to codify the discussions so far from this week into something we can all 
> read. There are still plenty of open discussion points and items up for 
> debate. Please read through this latest draft and see what's changed and help 
> assure that it properly captures the conversations. If you have any inputs 
> for the marked [[ Editor's Note ]] sections, please send them to the list by 
> next Thursday to give me opportunity to get any necessary changes in by the 
> cutoff date of Monday the 22nd.
> 
> Thanks for all of your hard work everyone, I think this is *really* coming 
> along now.
> 
>  -- Justin
> 
> On Feb 15, 2013, at 4:54 PM, [email protected] wrote:
> 
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts 
> > directories.
> > This draft is a work item of the Web Authorization Protocol Working Group 
> > of the IETF.
> >
> >       Title           : OAuth Dynamic Client Registration Protocol
> >       Author(s)       : Justin Richer
> >                          John Bradley
> >                          Michael B. Jones
> >                          Maciej Machulak
> >       Filename        : draft-ietf-oauth-dyn-reg-06.txt
> >       Pages           : 21
> >       Date            : 2013-02-15
> >
> > Abstract:
> >   This specification defines an endpoint and protocol for dynamic
> >   registration of OAuth Clients at an Authorization Server.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06
> >
> > A diff from the previous version is available at:
> > http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-06
> >
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > OAuth mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/oauth
> 
> _______________________________________________
> OAuth mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
>  
> -- 
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to