[OAUTH-WG] draft-ietf-oauth-revocation-05 Questions

Torsten, A colleague of mine and I were discussing what should occur when a Retail Customer desires to change the existing authorized access of a Third Party. During our discussion they asked "How does the Retail Customer know the Third Party actually issued a Token revocation request? Isn't t

Re: [OAUTH-WG] Additional Oauth Dynamic Client Registration Protocol Information

Justin, Thanks for the information. 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: donald.cof...@reminetworks.com

Re: [OAUTH-WG] Additional Oauth Dynamic Client Registration Protocol Information

Mike, Thanks for the information. 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: donald.cof...@reminetworks.com F

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

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

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 client", which does not sound right. Nat 2013/2/20 John Bradley > I am OK with that. >

Re: [OAUTH-WG] Additional Oauth Dynamic Client Registration Protocol Information

Additionally, there is an individual draft that registers LRDD Link Types for discovery using LRDD and HostMeta: http://tools.ietf.org/html/draft-wmills-oauth-lrdd-07 -- Justin On 02/20/2013 02:37 PM, Mike Jones wrote: Hi Don, Discovery is a process that happens before Registration, and th

Re: [OAUTH-WG] Additional Oauth Dynamic Client Registration Protocol Information

Hi Don, Discovery is a process that happens before Registration, and that's the point at which you would return the AS (and registration!) endpoints to the Client. The OAuth WG considered doing its own discovery work but ultimately decided to have that happen in the Apps Area WG instead, which

[OAUTH-WG] Additional Oauth Dynamic Client Registration Protocol Information

Justin, I understand the current Client Registration request and response information is based on the OPENID model for consistency, but has there been any thought or discussion of adding the AS OAuth 2.0 endpoint URIs as part of the registration response? I believe the addition of the endpoint

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

That's OK by me too. From: Justin Richer [mailto:jric...@mitre.org] Sent: Wednesday, February 20, 2013 11:03 AM To: Mike Jones Cc: Nat Sakimura; ; 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

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

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

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

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

OK, we should make the change then. Thanks for the input. -- Mike From: Tim Bray [mailto:twb...@google.com] Sent: Wednesday, February 20, 2013 9:22 AM To: Mike Jones Cc: Nat Sakimura; Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oaut

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

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

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 cli

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

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 a

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

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 o

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 > In OAuth, we have redirect_uri not redirect_url; should

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

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

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

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

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

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

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

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 U

Re: [OAUTH-WG] Using SAML2 Bearer for the authentication

On 19/02/13 14:27, Brian Campbell wrote: The scope of assertion based client authentication is only in OAuth and only for the client calling the AS's token endpoint. Defining a general HTTP auth scheme for assertions would have a much broader scope and be much more difficult to standardize. Unde