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]<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]
https://www.ietf.org/mailman/listinfo/oauth
