Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt

From: [email-masked]
Date: Fri, 15 Feb 2013 13:54:23 -0800

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/

---

From: "Richer, Justin P." <[email-masked]>
Date: Fri, 15 Feb 2013 22:00:27 +0000

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-masked] wrote:

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

---

From: Mike Jones <[email-masked]>
Date: Fri, 15 Feb 2013 22:15:11 +0000

+1

Thanks for doing this, Justin!

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richer, Justin P.
Sent: Friday, February 15, 2013 2:00 PM
To: [email-masked]
Cc: <[email-masked]>; <[email-masked]>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt

 -- Justin

---

From: "Donald F Coffin" <[email-masked]>
Date: Fri, 15 Feb 2013 18:01:09 -0800

Justin,

Section 5.1 of RFC6749 "OAuth 2.0 Authorization Framework" states:

	"The authorization server MUST include the HTTP "Cache-Control"
  	 response header field [RFC2616] with a value of "no-store" in any
   	response containing tokens, credentials, or other sensitive
   	information, as well as the "Pragma" response header field [RFC2616]
   	with a value of "no-cache"."

I've noticed several of the response examples in the current and previous versions of "draft-ietf-oauth-dyn-reg-xx.txt" fail to include the required "Pragma: "no-cache" directive.  I assume this is an oversight and am merely pointing out that it needs to be included.

Best regards,
Don
Donald F. Coffin
Founder/CTO

REMI Networks
22751 El Prado Suite 6216
Rancho Santa Margarita, CA  92688-3836

Phone:      (949) 636-8571
Email:       [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, February 15, 2013 1:54 PM
To: [email-masked]
Cc: [email-masked]
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt

Abstract:

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 17 Feb 2013 11:54:38 +0100

Hi Justin,

the new revision seems to catch the state of discussion and is 
consistent. Thank's for bringing this topic forward.

On your editor's not in section 4.2.: In my opinion, the 404 due to a 
none-existing resource should precede the 403. I would suggest to point 
out your thoughts on the access token. But as with any HTTP request, 
there could be other ways to authenticate to this endpoint. I therefore 
would not connect both aspects to much.

section 4.3

"This request MUST include all fields described in Client Metadata
    (Section 2) as returned to the Client from a previous register, read,
    or update operation."

Just to make sure I got it. Any data element omitted in this request is 
deleted/reset by the AS?

section 5.1

Something seems to be missing at

"The response contains the following fields:

    , as well as a Client Secret if this client is a confidential client."

regards,
Torsten.

---

From: Justin Richer <[email-masked]>
Date: Mon, 18 Feb 2013 09:24:29 -0500

The text in question refers to responses from the Token Endpoint, 
whereas this spec deals with a separate endpoint, the Client 
Registration Endpoint. Therefore, the text doesn't directly apply.

However, it's not bad advice to replicate that here since we are issuing 
a special-use access token along with the response.

  -- Justin

---

From: Justin Richer <[email-masked]>
Date: Mon, 18 Feb 2013 09:31:54 -0500

On 02/17/2013 05:54 AM, Torsten Lodderstedt wrote:
> none-existing resource should precede the 403. I would suggest to 
> point out your thoughts on the access token. But as with any HTTP 
> request, there could be other ways to authenticate to this endpoint. I 
> therefore would not connect both aspects to much.
>

 From our own implementation, the code that processes the token would 
fire (and fail) long before the code that checks if the client is valid 
gets reached. So for us, checking if the client exists in the first 
place is difficult.

What if we just say it's a 403 if either the client or the token are 
invalid?

> Just to make sure I got it. Any data element omitted in this request 
> is deleted/reset by the AS?

That's the intent. The AS is free to fill in or reject any fields the 
client omits, if it wants to.

>    , as well as a Client Secret if this client is a confidential client."

Vestigial formatting from shuffling sections around. Thanks for catching 
that!

  -- Justin

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

---

From: John Bradley <[email-masked]>
Date: Mon, 18 Feb 2013 12:26:20 -0300

inline
On 2013-02-18, at 11:31 AM, Justin Richer <[email-masked]> wrote:

>> the new revision seems to catch the state of discussion and is consistent. Thank's for bringing this topic forward.
>> 
>> On your editor's not in section 4.2.: In my opinion, the 404 due to a none-existing resource should precede the 403. I would suggest to point out your thoughts on the access token. But as with any HTTP request, there could be other ways to authenticate to this endpoint. I therefore would not connect both aspects to much.
>> 
> 
> From our own implementation, the code that processes the token would fire (and fail) long before the code that checks if the client is valid gets reached. So for us, checking if the client exists in the first place is difficult.
> 
> What if we just say it's a 403 if either the client or the token are invalid?

This is the wording I put in the Connect version

When a read error condition occurs, the Client Registration Access Endpoint returns a HTTP 403 Forbidden status code. This indicates that the Access Token is invalid or the Client record requested is invalid or non-existent. Note that for security reasons, to inhibit brute force attacks, endpoints MUST NOT return 404 Not Found error codes.

From a security point of view differentiating the two is bad as it helps an attacker find valid notes to brute force.  Ideally you want an attacker to spend time truing to break into resources that don't exist as well as ones that do.

John B.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 18 Feb 2013 21:04:53 +0100

>or non-existent. Note that for security reasons, to inhibit brute force
>attacks, endpoints MUST NOT return 404 Not Found error codes.
>
>From a security point of view differentiating the two is bad as it
>helps an attacker find valid notes to brute force.  Ideally you want an
>attacker to spend time truing to break into resources that don't exist
>as well as ones that do.

Good point!

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 20 Feb 2013 10:58:24 -0500

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-masked]>

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

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: Mike Jones <[email-masked]>
Date: Wed, 20 Feb 2013 16:04:39 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Nat Sakimura
Sent: Wednesday, February 20, 2013 7:58 AM
To: <[email-masked]>; Richer, Justin P.; John Bradley
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt

Thanks Justin.

Nat
2013/2/15 Richer, Justin P. <[email-masked]<mailto:[email-masked]>>
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.

 -- Justin

On Feb 15, 2013, at 4:54 PM, [email-masked]<mailto:[email-masked]> wrote:

> [email-masked]<mailto:[email-masked]>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: John Bradley <[email-masked]>
Date: Wed, 20 Feb 2013 13:23:29 -0300

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-masked]> 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: Tim Bray <[email-masked]>
Date: Wed, 20 Feb 2013 08:34:15 -0800

In OAuth, we have redirect_uri not redirect_url; should this be
registration_access_uri for consistency? -T

On Wed, Feb 20, 2013 at 8:23 AM, John Bradley <[email-masked]> 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-masked] [mailto:[email-masked]] *On Behalf
> Of *Nat Sakimura
> *Sent:* Wednesday, February 20, 2013 7:58 AM
> *To:* <[email-masked]>; Richer, Justin P.; John Bradley
> *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt****
> ** **
> Thanks Justin.
>
> It is not representing "Client Registration Access". ****
> What does "Client Registration Access" mean? ****
>
> Nat****
> 2013/2/15 Richer, Justin P. <[email-masked]>****
>  -- Justin****
> https://www.ietf.org/mailman/listinfo/oauth****
>
>
> ****
> ** **
> --
> Nat Sakimura (=nat)****

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 20 Feb 2013 11:53:27 -0500

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-masked]>

> @_nat_en****

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 20 Feb 2013 11:56:45 -0500

You are right. I am in the camp recommending the use of URL when it is a
concrete endpoint and URI when it includes something that is only abstract,
but since OAuth standardized on "uri", we may as well do so here.

Nat

2013/2/20 Tim Bray <[email-masked]>

>>  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
>> it doesn’t say anything it being the registration that you’re accessing.*
>> ***
>>
>> *From:* [email-masked] [mailto:[email-masked]] *On
>> Behalf Of *Nat Sakimura

---

From: Mike Jones <[email-masked]>
Date: Wed, 20 Feb 2013 17:00:17 +0000

Tim, as background, this came from the OpenID Connect specs, where we tried to consistently use the convention that the locator for any resource that can be retrieved from the specified location be called a URL, whereas any identifier that may not be retrievable is called a URI.  That was done as an aid to developer understanding of the specifications.

If the use of "URL" is deprecated by the IETF in favor of always just using "URI", I suppose we could change that, but if it's going to change, it should be soon.

                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Nat Sakimura
Sent: Wednesday, February 20, 2013 8:57 AM
To: Tim Bray
Cc: <[email-masked]>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt

You are right. I am in the camp recommending the use of URL when it is a concrete endpoint and URI when it includes something that is only abstract, but since OAuth standardized on "uri", we may as well do so here.

Nat
2013/2/20 Tim Bray <[email-masked]<mailto:[email-masked]>>
In OAuth, we have redirect_uri not redirect_url; should this be registration_access_uri for consistency? -T

On Wed, Feb 20, 2013 at 8:23 AM, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:
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-masked]<mailto:[email-masked]>> wrote:

                                                            -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:oauth-<mailto:oauth->[email-masked]<mailto:[email-masked]>] On Behalf Of Nat Sakimura
Sent: Wednesday, February 20, 2013 7:58 AM
To: <[email-masked]<mailto:[email-masked]>>; Richer, Justin P.; John Bradley
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt

Thanks Justin.

Nat

 -- Justin

---

From: Mike Jones <[email-masked]>
Date: Wed, 20 Feb 2013 17:02:50 +0000

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-masked]]
Sent: Wednesday, February 20, 2013 8:53 AM
To: Mike Jones
Cc: <[email-masked]>; Richer, Justin P.; John Bradley
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt

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

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>

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-masked]<mailto:[email-masked]>>
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.

                                                            -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Nat Sakimura
Sent: Wednesday, February 20, 2013 7:58 AM
To: <[email-masked]<mailto:[email-masked]>>; Richer, Justin P.; John Bradley

Thanks Justin.

Nat

 -- Justin

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 20 Feb 2013 12:20:16 -0500

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

>  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-masked]]
> *Sent:* Wednesday, February 20, 2013 8:53 AM
> *To:* Mike Jones
> *Cc:* <[email-masked]>; Richer, Justin P.; John Bradley
>
> I have read the whole thing and still --- ****
>
> ** **
>
> There are several weakness. ****
>
> ** **
>
> is broken. ****
> "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>****
>
> ** **
>
> Remember, a URL is represents a "thing". ****
>
> The name of the endpoint should represent the "thing". ****
>
> ** **
>
> the time being.) ****
> *registration **n.*****
> *1*
> *2*
> *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-masked]>****
>
> *To:* <[email-masked]>; Richer, Justin P.; John Bradley****
>
>
> Thanks Justin.****

---

From: Tim Bray <[email-masked]>
Date: Wed, 20 Feb 2013 09:21:30 -0800

Yes, “URL” is strongly and clearly deprecated in RFC3986 section 1.1.3; one
of the reasons is that the distinction between “locator” and “identifier”
which sounds like it should be easy, turns out to lead to theological
bikeshed discussions almost inevitably, and in fact be shaky in practice.
 -T

On Wed, Feb 20, 2013 at 9:00 AM, Mike Jones <[email-masked]>wrote:

>  Tim, as background, this came from the OpenID Connect specs, where we
> tried to consistently use the convention that the locator for any resource
> that can be retrieved from the specified location be called a URL, whereas
> any identifier that may not be retrievable is called a URI.  That was done
> as an aid to developer understanding of the specifications.****
>
> ** **
>
> If the use of “URL” is deprecated by the IETF in favor of always just
> using “URI”, I suppose we could change that, but if it’s going to change,
> it should be soon.****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> ** **
>
> *Sent:* Wednesday, February 20, 2013 8:57 AM
> *To:* Tim Bray
> *Cc:* <[email-masked]>
> but since OAuth standardized on "uri", we may as well do so here. ****
>
> ** **
>
> Nat****
>
> 2013/2/20 Tim Bray <[email-masked]>****
>
> registration_access_uri for consistency? -T****
>
> ** **
>
> On Wed, Feb 20, 2013 at 8:23 AM, John Bradley <[email-masked]> wrote:**
> **
>
> I think registration_access_url is OK.    I haven't heard any better names
> yet.****
>
> ** **
>
> John B.****
>
> ** **
>

---

From: Mike Jones <[email-masked]>
Date: Wed, 20 Feb 2013 17:57:42 +0000

OK, we should make the change then.  Thanks for the input.

                                                            -- Mike

From: Tim Bray [mailto:[email-masked]]
Sent: Wednesday, February 20, 2013 9:22 AM
To: Mike Jones
Cc: Nat Sakimura; <[email-masked]>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt

Yes, “URL” is strongly and clearly deprecated in RFC3986 section 1.1.3; one of the reasons is that the distinction between “locator” and “identifier” which sounds like it should be easy, turns out to lead to theological bikeshed discussions almost inevitably, and in fact be shaky in practice.  -T
On Wed, Feb 20, 2013 at 9:00 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Tim, as background, this came from the OpenID Connect specs, where we tried to consistently use the convention that the locator for any resource that can be retrieved from the specified location be called a URL, whereas any identifier that may not be retrievable is called a URI.  That was done as an aid to developer understanding of the specifications.

If the use of “URL” is deprecated by the IETF in favor of always just using “URI”, I suppose we could change that, but if it’s going to change, it should be soon.

                                                            -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Nat Sakimura
Sent: Wednesday, February 20, 2013 8:57 AM
To: Tim Bray
Cc: <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt

Nat

John B.

                                                            -- Mike

Thanks Justin.

Nat

 -- Justin

---

From: Justin Richer <[email-masked]>
Date: Wed, 20 Feb 2013 13:10:56 -0500

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:
> "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
>
>     “_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-masked]
>     <mailto:[email-masked]>]
>     *Cc:* <[email-masked] <mailto:[email-masked]>>; Richer, Justin P.;
>     John Bradley
>
>
>     *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
>
>     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.
>
>     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.
>
>     *access */n./
>     /*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>
>
>     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*
>
>     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
>
>     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-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>]
>     *On Behalf Of *Nat Sakimura
>     *To:* <[email-masked] <mailto:[email-masked]>>; Richer, Justin P.;
>     John Bradley
>
>
>     *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
>
>     Thanks Justin.
>
>
>
>     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.
>
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Mike Jones <[email-masked]>
Date: Wed, 20 Feb 2013 18:13:32 +0000

SGTM

From: Justin Richer [mailto:[email-masked]]
Sent: Wednesday, February 20, 2013 10:11 AM
To: Nat Sakimura
Cc: Mike Jones; <[email-masked]>; 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.

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

                                                            -- Mike

From: Nat Sakimura [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, February 20, 2013 8:53 AM
To: Mike Jones
Cc: <[email-masked]<mailto:[email-masked]>>; Richer, Justin P.; John Bradley

access n.

1

registration n.

1

Nat

                                                            -- Mike

Thanks Justin.

Nat

 -- Justin

---

From: Justin Richer <[email-masked]>
Date: Wed, 20 Feb 2013 14:03:12 -0500

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-masked]]
> *Sent:* Wednesday, February 20, 2013 10:11 AM
> *To:* Nat Sakimura
> *Cc:* Mike Jones; <[email-masked]>; John Bradley
> 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.
>
>
>     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
>
>     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
>
>     /*a*/*:* onset <http://www.merriam-webster.com/dictionary/onset> 2
>
>     /*b*/*:* a fit of intense feeling *:* outburst
>     <http://www.merriam-webster.com/dictionary/registered> *:*
>     enrollment <http://www.merriam-webster.com/dictionary/enrollment>
>
>     *4*
>
>     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
>     let's do it ASAP, before the OpenID Connect Implementer's Drafts
>     are published.)
>
>     -- Mike
>

---

From: Mike Jones <[email-masked]>
Date: Wed, 20 Feb 2013 19:08:43 +0000

That's OK by me too.

From: Justin Richer [mailto:[email-masked]]
Sent: Wednesday, February 20, 2013 11:03 AM
To: Mike Jones
Cc: Nat Sakimura; <[email-masked]>; John Bradley
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt

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.

This has the nice side effect of being more parallel with "reigstration_access_token".

 -- Justin

From: Justin Richer [mailto:[email-masked]]
Sent: Wednesday, February 20, 2013 10:11 AM
To: Nat Sakimura
Cc: Mike Jones; <[email-masked]><mailto:[email-masked]>; John Bradley
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt

 -- Justin

Nat

                                                            -- Mike

access n.

1

registration n.

1

Nat

                                                            -- Mike

Thanks Justin.

Nat

 -- Justin

---

From: John Bradley <[email-masked]>
Date: Wed, 20 Feb 2013 17:00:20 -0300

I am OK with that.
On 2013-02-20, at 4:03 PM, Justin Richer <[email-masked]> wrote:

>> 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
>>  
>> a : onset 2
>> b : a fit of intense feeling : outburst
>> 2
>> d : the act or an instance of accessing
>> 3
>> : the act of registering
>> : an entry in a register
>> : the number of individuals registered : enrollment
>> 4

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 20 Feb 2013 15:32:26 -0500

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-masked]>

> 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.
>
> SGTM****
> *From:* Justin Richer [mailto:[email-masked] <[email-masked]>]
> *Cc:* Mike Jones; <[email-masked]> <[email-masked]>; John Bradley
> 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.
>
>
> On 02/20/2013 12:20 PM, Nat Sakimura wrote:****
>
> about the client.  ****
> *Cc:* <[email-masked]>; Richer, Justin P.; John Bradley****
>
>
> *1*****
> *2*****
> *3*****
> *1*****
> *2*****
> *3*****
> *4*****
> *5*****
> Nat Sakimura (=nat) ****

---

From: Mike Jones <[email-masked]>
Date: Wed, 20 Feb 2013 20:37:09 +0000

I believe the semantic intent of "registration_client_uri" is "client uri to be used for registration operations", just like the semantic intent of "registration_access_token" is "access token to be used for registration operations".  Both perfectly meaningful constructions.

From: Nat Sakimura [mailto:[email-masked]]
Sent: Wednesday, February 20, 2013 12:32 PM
To: John Bradley
Cc: Justin Richer; Mike Jones; <[email-masked]>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt

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-masked]<mailto:[email-masked]>>
I am OK with that.

On 2013-02-20, at 4:03 PM, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:

 -- Justin

 -- Justin

Nat

                                                            -- Mike

access n.

1

registration n.

1

Nat

                                                            -- Mike

Thanks Justin.

Nat

 -- Justin

---

From: Justin Richer <[email-masked]>
Date: Thu, 21 Feb 2013 09:04:47 -0500

With this in mind, we might want to change *all* of the _url parameters 
to _uri instead, not just this new one. Are folks in favor of this?

  -- Justin

On 02/20/2013 12:57 PM, Mike Jones wrote:
> *From:*Tim Bray [mailto:[email-masked]]
> *Sent:* Wednesday, February 20, 2013 9:22 AM
> *To:* Mike Jones
> *Cc:* Nat Sakimura; <[email-masked]>
> Yes, "URL" is strongly and clearly deprecated in RFC3986 section 
> 1.1.3; one of the reasons is that the distinction between "locator" 
> and "identifier" which sounds like it should be easy, turns out to 
> lead to theological bikeshed discussions almost inevitably, and in 
> fact be shaky in practice.  -T
>
> On Wed, Feb 20, 2013 at 9:00 AM, Mike Jones 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> tried to consistently use the convention that the locator for any 
> resource that can be retrieved from the specified location be called a 
> URL, whereas any identifier that may not be retrievable is called a 
> URI.  That was done as an aid to developer understanding of the 
> specifications.
>
> If the use of "URL" is deprecated by the IETF in favor of always just 
> using "URI", I suppose we could change that, but if it's going to 
> change, it should be soon.
>
> -- Mike
>
> [mailto:[email-masked] <mailto:[email-masked]>] *On 
> Behalf Of *Nat Sakimura
> *Cc:* <[email-masked] <mailto:[email-masked]>>
> You are right. I am in the camp recommending the use of URL when it is 
> a concrete endpoint and URI when it includes something that is only 
> abstract, but since OAuth standardized on "uri", we may as well do so 
> here.
>
> Nat
>
> 2013/2/20 Tim Bray <[email-masked] <mailto:[email-masked]>>
>
> On 2013-02-20, at 1:04 PM, Mike Jones <[email-masked] 
> <mailto:[email-masked]>> 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.
>
> 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
>
> [mailto:oauth- <mailto:oauth->[email-masked] 
> <mailto:[email-masked]>] *On Behalf Of *Nat Sakimura
> 2013/2/15 Richer, Justin P. <[email-masked] <mailto:[email-masked]>>
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 21 Feb 2013 17:31:21 +0000

Yes - per Tim's reference, we'll likely be required to do this at some point before achieving RFC status, so better to do it now than later.

FYI, OpenID Connect Registration just made these changes, for exactly this reason.

                                                            Cheers,
                                                            -- Mike

From: Justin Richer [mailto:[email-masked]]
Sent: Thursday, February 21, 2013 6:05 AM
To: Mike Jones
Cc: Tim Bray; <[email-masked]>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt

With this in mind, we might want to change *all* of the _url parameters to _uri instead, not just this new one. Are folks in favor of this?

 -- Justin

                                                            -- Mike

From: Tim Bray [mailto:[email-masked]]
Sent: Wednesday, February 20, 2013 9:22 AM
To: Mike Jones
Cc: Nat Sakimura; <[email-masked]><mailto:[email-masked]>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt

Yes, "URL" is strongly and clearly deprecated in RFC3986 section 1.1.3; one of the reasons is that the distinction between "locator" and "identifier" which sounds like it should be easy, turns out to lead to theological bikeshed discussions almost inevitably, and in fact be shaky in practice.  -T
On Wed, Feb 20, 2013 at 9:00 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Tim, as background, this came from the OpenID Connect specs, where we tried to consistently use the convention that the locator for any resource that can be retrieved from the specified location be called a URL, whereas any identifier that may not be retrievable is called a URI.  That was done as an aid to developer understanding of the specifications.

                                                            -- Mike

Nat

John B.

                                                            -- Mike

Thanks Justin.

Nat

 -- Justin

OAuth mailing list