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]
<mailto:[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]
<mailto:[email protected]>]
*Sent:* Wednesday, February 20, 2013 8:53 AM
*To:* Mike Jones
*Cc:* <[email protected] <mailto:[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]
<mailto:[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]>
[mailto:[email protected] <mailto:[email protected]>]
*On Behalf Of *Nat Sakimura
*Sent:* Wednesday, February 20, 2013 7:58 AM
*To:* <[email protected] <mailto:[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]
<mailto:[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]
<mailto:[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] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected] <mailto:[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
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
