Hmmm. *registered *is adjective, not verb.
registration client is noun + noun, and sounds funny to me. When expanded, it becomes "an entry in a register<http://www.merriam-webster.com/dictionary/register> client", which does not sound right. Nat 2013/2/20 John Bradley <[email protected]> > I am OK with that. > > On 2013-02-20, at 4:03 PM, Justin Richer <[email protected]> wrote: > > On second thought, how about "registration_client_uri"? It's the URI for > a particular client's registration. Use of the verb "registered" makes it > sound like the result of an action that the client took, as if the client > itself had registered the URI. That's obviously not the case, and we don't > want to convey that. > > So, new proposed name: "registration_client_uri" > > This has the nice side effect of being more parallel with > "reigstration_access_token". > > -- Justin > > On 02/20/2013 01:13 PM, Mike Jones wrote: > > SGTM**** > > > > *From:* Justin Richer [mailto:[email protected] <[email protected]>] > *Sent:* Wednesday, February 20, 2013 10:11 AM > *To:* Nat Sakimura > *Cc:* Mike Jones; <[email protected]> <[email protected]>; John Bradley > *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt**** > > ** ** > > I like "registered_client_uri", given all of the other discussions on this > thread, because: > > URL/URI: It *is* a URL, and an https one at that, but if the IETF > convention is to call it URI, then I'm fine with that. > > registered_client/registration_access: The former is a good description of > what's actually *at* the URL, which fits better with the RESTful entity > model. I think Nat's criticisms about the original formation of the > parameter name are spot on, though at the time we hadn't heard anything > better. > > > So I'd like to change it to "registered_client_uri" in the next draft. > > -- Justin**** > > On 02/20/2013 12:20 PM, Nat Sakimura wrote:**** > > I have thought about that as well. The the reason I added "info" or > "metadata" was that what was behind the URL is not the client itself. By > "client registration", I suppose you mean "client entry in the register" > (cf. *registration **n* 2.) . It is the "registered data/info/metadata" > about the client. **** > > ** ** > > Nat**** > > 2013/2/20 Mike Jones <[email protected]>**** > > I could live with “registered_client_url”. I think that adding > “_metadata” or “_info” is incorrect, because what’s being accessed is the > client’ registration – not just metadata or info about the client’s > registration (although that information can be retrieved as one aspect of > the operations on the client’s registration).**** > > **** > > -- Mike**** > > **** > > *From:* Nat Sakimura [mailto:[email protected]] > *Sent:* Wednesday, February 20, 2013 8:53 AM > *To:* Mike Jones > *Cc:* <[email protected]>; Richer, Justin P.; John Bradley**** > > > *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt**** > > **** > > I have read the whole thing and still --- **** > > **** > > Your argument that it is the place for using "registration access token" > thus should have a parallel name "registration access url" is very weak. > There are several weakness. **** > > **** > > First, "registration access token" actually is "registration" + "access > token". Extracting "registration access" from "registration access token" > is broken. **** > > **** > > Secondly, access token is used to against any protected > resource. Recommending to use the word "access" in naming protected > resources is broken. Should we rename Userinfo endpoint to something like > "Userinfo Access Endpoint"? I do not think so. **** > > **** > > Thirdly, the term "Registration Access" does not seem to be meaningful. ** > ** > > When you say "access", I suppose you are using the noun version of it. *** > * > > (If you are using the verb, then I am even more against as a URL should > not contain a verb.) **** > > **** > > According to the Webster, access (n.) is defined as: **** > > **** > > *access **n.***** > > **** > > *1***** > > *a* *:* onset <http://www.merriam-webster.com/dictionary/onset> 2**** > > *b* *:* a fit of intense feeling *:* > outburst<http://www.merriam-webster.com/dictionary/outburst> > **** > > *2***** > > *a* *:* permission, liberty, or ability to enter, approach, or pass to > and from a place or to approach or communicate with a person or thing**** > > *b* *:* freedom or ability to obtain or make use of something**** > > *c* *:* a way or means of access**** > > *d* *:* the act or an instance of > accessing<http://www.merriam-webster.com/dictionary/accessing> > **** > > *3***** > > *:* an increase by addition <a sudden *access* of wealth>**** > > **** > > Replacing "access" with any of the definition above does not seem to work. > **** > > **** > > Remember, a URL is represents a "thing". **** > > The name of the endpoint should represent the "thing". **** > > **** > > I am merginally OK with "client registration url" leveraging on the > definition 2. below (again from Webster -- my OED subscription lapsed for > the time being.) **** > > **** > > *registration **n.***** > > **** > > *1***** > > *:* the act of > registering<http://www.merriam-webster.com/dictionary/registering> > **** > > *2***** > > *:* an entry in a register<http://www.merriam-webster.com/dictionary/register> > **** > > *3***** > > *:* the number of individuals > registered<http://www.merriam-webster.com/dictionary/registered> > *:* enrollment <http://www.merriam-webster.com/dictionary/enrollment>**** > > *4***** > > *a* *:* the art or act of selecting and adjusting pipe organ stops**** > > *b* *:* the combination of stops selected for performing a particular > organ work**** > > *5***** > > *:* a document certifying an act of registering**** > > **** > > However, since the most common use of "registration" is actually *1*above, it > still is confusing. If you really want to emphasize the fact that > it has been registered, then something like "registered client info uri" or > "registered client metadata uri" would be better. **** > > **** > > Nat**** > > **** > > **** > > 2013/2/20 Mike Jones <[email protected]>**** > > 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**** > > > > **** > > **** > > -- > Nat Sakimura (=nat)**** > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en**** > > > > **** > > ** ** > > -- > Nat Sakimura (=nat) **** > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en**** > > ** ** > > > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
