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:
OK, we should make the change then. Thanks for the input.
-- Mike
*From:*Tim Bray [mailto:[email protected]]
*Sent:* Wednesday, February 20, 2013 9:22 AM
*To:* Mike Jones
*Cc:* Nat Sakimura; <[email protected]>
*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 protected] <mailto:[email protected]>> 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 protected] <mailto:[email protected]>
[mailto:[email protected] <mailto:[email protected]>] *On
Behalf Of *Nat Sakimura
*Sent:* Wednesday, February 20, 2013 8:57 AM
*To:* Tim Bray
*Cc:* <[email protected] <mailto:[email protected]>>
*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 protected] <mailto:[email protected]>>
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 protected]
<mailto:[email protected]>> 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 protected]
<mailto:[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]>
[mailto:oauth- <mailto:oauth->[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
_______________________________________________
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
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
