Re: [OAUTH-WG] Dynamic Client Registration: comment on metadata requirements

Well, I think it's confusing, then. To me, it reads like a typo since it's formatted as a verb. I really think it should line up with the actual name of the parameter, or it shouldn't be formatted as a verb. So I'd suggest either: register their "redirect_uris" value or: register their

Re: [OAUTH-WG] Dynamic Client Registration: comment on metadata requirements

This isn't a typo. They are registering their "redirect_uri" values. They do so using the "redirect_uris" parameter. -- Mike From: Richer, Justin P. [mailto:jric...@mitre.org] Sent: Tuesday, July 08, 2014 8:41 PM To: Mike Jones Cc: oa

Re: [OAUTH-WG] Dynamic Client Registration: comment on metadata requirements

According to RFC 6749, it must be a MUST. http://tools.ietf.org/html/rfc6749#section-2 says: When registering a client, the client developer SHALL: o provide its client redirection URIs as described in Section 3.1.2, SHALL doesn't fulfi

Re: [OAUTH-WG] Dynamic Client Registration: comment on metadata requirements

What about the whole issue of redirect_uri fragments? Are there any issues where a client for some reason can’t register a perm URI at registration time? Phil @independentid www.independentid.com phil.h...@oracle.com On Jul 8, 2014, at 8:39 PM, Richer, Justin P. wrote: > I can see where y

Re: [OAUTH-WG] Dynamic Client Registration: comment on metadata requirements

Also, I just noticed that paragraph has a typo: "redirect_uri" should be "redirect_uris". -- Justin On Jul 8, 2014, at 11:39 PM, Justin Richer mailto:jric...@mitre.org>> wrote: I can see where you're going with it. Requiring clients to use it implies that servers need to enforce it. In the s

Re: [OAUTH-WG] Dynamic Client Registration: comment on metadata requirements

I can see where you're going with it. Requiring clients to use it implies that servers need to enforce it. In the security considerations we currently have: For clients that use redirect-based grant types such as "authorization_code" and "implicit", authorization servers MUST require cl

Re: [OAUTH-WG] Dynamic Client Registration: comment on metadata requirements

That's close but not quite right, since use is required by clients when using redirect-based grant types. We could however, use this language: The implementation and use of all client metadata fields is OPTIONAL, other than "redirect_uris" which is REQUIRED for authorization servers that supp

Re: [OAUTH-WG] Dynamic Client Registration: IPR Confirmation

Yes Nat and I mentioned the need for attribution to Hannes. Having that also helps clarify the relationship between the specs for readers. Sent from my iPhone > On Jul 8, 2014, at 10:14 PM, Mike Jones wrote: > > Thinking about this some more, there is one IPR issue that we need to address >

Re: [OAUTH-WG] Dynamic Client Registration: comment on metadata requirements

Yes that is reasonable. Sent from my iPhone > On Jul 8, 2014, at 9:44 PM, "Richer, Justin P." wrote: > > In draft -18, we clarified the optionality of the client metadata parameters > in § 2 with new text, including the sentences: > > The implementation and use of all client metadata fields

Re: [OAUTH-WG] Dynamic Client Registration: IPR Confirmation

Thinking about this some more, there is one IPR issue that we need to address before publication. This specification is a derivative work from the OpenID Connect Dynamic Registration specification http://openid.net/specs/openid-connect-registration-1_0.html. Large portions of the text were co

[OAUTH-WG] Introspection draft -06

I've updated the introspection draft based on the handful of comments that I received from -05 to allow these discussions to be incorporated into the discussion going forward: http://tools.ietf.org/id/draft-richer-oauth-introspection-06.html -- Justin __

[OAUTH-WG] Dynamic Client Registration: comment on metadata requirements

In draft -18, we clarified the optionality of the client metadata parameters in § 2 with new text, including the sentences: The implementation and use of all client metadata fields is OPTIONAL, other than "redirect_uris". redirect_uris (...) Authorization servers MUST implement support for th

Re: [OAUTH-WG] Dynamic Client Registration: application_type

Right, that's how it's used in Connect, which defines only redirect-based flows. However, the OAuth version needs to be more general purpose. It seems like this parameter really does need more discussion in the group before it should be added to the spec, and therefore I don't think it's approp

Re: [OAUTH-WG] Dynamic Client Registration: application_type

If I understand correctly, this parameter is used to appropriately constrain the schema of the Redirect URIs at the time of the registration and is not about fulfilling the Client Type registration requirement in section 2.1. So, making go or no-go decision based on the discussion around section 2.

Re: [OAUTH-WG] Dynamic Client Registration: application_type

This value was introduced in -18, and it's a direct port from OpenID Connect. It was never in the OAuth Dynamic Registration spec, and though it has been in the OpenID Connect Dynamic Registration spec for a very long time, I think it was a mistake to add it in for several reasons: First, the s

Re: [OAUTH-WG] Dynamic Client Registration: application_type

Ok. Phil > On Jul 8, 2014, at 13:38, Mike Jones wrote: > > I put it back because otherwise, we wouldn't be meeting one of the > requirements of the RFC 6749. If you look at the client registration section > http://tools.ietf.org/html/rfc6749#section-2, you’ll see that registering > redirec

Re: [OAUTH-WG] Dynamic Client Registration: application_type

I put it back because otherwise, we wouldn't be meeting one of the requirements of the RFC 6749. If you look at the client registration section http://tools.ietf.org/html/rfc6749#section-2, you'll see that registering redirect_uri values is required, as is registering the client type. Without

Re: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri

+1 to John's #3. The others could maybe be described in somewhat abstract terms as examples of those "higher level protocols that use signing or encryption." On Tue, Jul 8, 2014 at 12:33 PM, John Bradley wrote: > In Connect these public keys are used to: > 1 verify the signature of request object

Re: [OAUTH-WG] Dynamic Client Registration: application_type

It was taken out and then put back in as it is a common parameter used by a number of AS. We have it in Connect, the best reason for keeping it is to stop people from coming up with a new parameter for the same thing because they haven't looked at the Connect version. John B. On Jul 8, 2014, a

Re: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri

In Connect these public keys are used to: 1 verify the signature of request objects (Signed Requests), something not in OAuth yet, and part of what the description calls higher level protocols. 2 encrypt the responses from the user_info endpoint or id_token (also not part of OAuth directly at thi

Re: [OAUTH-WG] Dynamic Client Registration: application_type

Does this need to be in the spec? I believe we’ve already said that others can add attributes as they need. Phil @independentid www.independentid.com phil.h...@oracle.com On Jul 8, 2014, at 11:56 AM, John Bradley wrote: > The application_type is collected as part of current registration by

Re: [OAUTH-WG] Dynamic Client Registration: policy_uri

I am OK with clarifying the description as privacy/data protection policy. I don't think it needs privacy in the parameter name. On Jul 8, 2014, at 2:59 PM, Mike Jones wrote: > I agree with Nat’s assessment. I’m fine updating the textual description of > the parameter, but we should not cons

Re: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri

Was there specific language that had been discussed to be added for this? If not, could someone please create some? Thanks, -- Mike -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofen

Re: [OAUTH-WG] Dynamic Client Registration: policy_uri

I agree with Nat’s assessment. I’m fine updating the textual description of the parameter, but we should not consider breaking changes to the parameter names at this point. Do you have specific wording in mind, Hannes? -- Mike From:

Re: [OAUTH-WG] Dynamic Client Registration: application_type

The application_type is collected as part of current registration by Google and some other OAuth providers as part of registering redirect uri. The text was cut down to allow more flexibility in OAuth. Connect requires registration of redirect_uri and is more ridged about it than OAuth 2. Do y

Re: [OAUTH-WG] Dynamic Client Registration: IPR Confirmation

I likewise do not hold any IPR on these specs. From: Phil Hunt Sent: ‎7/‎8/‎2014 9:11 AM To: Hannes Tschofenig Cc: Mike Jones; John Bradley;

Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

Perhaps I’m just in a minority that lacks the intellectual prowess to really understand the WS* specifications but, to me anyway, saying that it’s clearly defined there is standing on very shaky ground. When I read §1.3 of draft-jones-oauth-token-exchange-00[0], it sure sounded to me like it was d

Re: [OAUTH-WG] Dynamic Client Registration: IPR Confirmation

I confirm I have no IPR disclosures on this document. Phil > On Jul 8, 2014, at 4:54, Hannes Tschofenig wrote: > > Hi Phil, John, Maciej, Justin, Mike, > > I am working on the shepherd writeup for the dynamic client registration > document and one item in the template requires me to indicate

Re: [OAUTH-WG] Fwd: Re: New Token Introspection Draft

Sorry for a tardy reply. I was very much under the water till today. While your mental model works and is kind of stated in the introduction, it does not seem to be codified in the draft in a normative language. Perhaps doing so would be a good idea. Even if the introspection endpoint is to be st

Re: [OAUTH-WG] Dynamic Client Registration: IPR Confirmation

I can confirm that I have no IPR disclosures to make on these documents. On Jul 8, 2014, at 8:01 AM, Justin Richer wrote: > I can confirm that I have no IPR disclosures to make regarding these > documents. > > --Justin > > /sent from my phone/ > > On Jul 8, 2014 7:54 AM, Hannes Tschofenig w

Re: [OAUTH-WG] Dynamic Client Registration: policy_uri

I am not against using the term "Privacy Policy" in the description. Depending on the jurisdiction and language, direct translation of such can be "Data Protection Policy", "Personal Data Protection Policy", etc., instead so just dodging it by avoiding the label would be more politically neutral, b

Re: [OAUTH-WG] Dynamic Client Registration: application_type

This additional information makes a lot of sense. As you said in an earlier mail, the attempt to copy text from the OpenID Connect spec failed a bit... On 07/08/2014 02:49 PM, Nat Sakimura wrote: > I suppose authors has imported one of the security feature of OpenID > Connect here as well. In the

Re: [OAUTH-WG] Dynamic Client Registration: policy_uri

For example, even Facebook calls this stuff "Privacy Policy URL". On 07/08/2014 02:43 PM, Nat Sakimura wrote: > policy_uri came down from OpenID Connect Dynamic Client Registraiton 1.0 > [1]. > > It goes: > > policy_uri > OPTIONAL. URL that the Relying Party Client provides to the End-User

Re: [OAUTH-WG] Dynamic Client Registration: application_type

I suppose authors has imported one of the security feature of OpenID Connect here as well. In the Dynamic Client Registration standard, which is a bit longer than IETF version. You can see the reason from it: application_typeOPTIONAL. Kind of the application. The default, if omitted, is web. The d

[OAUTH-WG] Shepherd Writeup for Dynamic Client Registration Draft

Hi all, I am working on the shepherd writeup for the dynamic client registration draft. You can find the latest draft here: https://github.com/hannestschofenig/tschofenig-ids/blob/master/shepherd-writeups/Writeup_OAuth_DynamicClientRegistration.txt As you can see it is still incomplete. I would

Re: [OAUTH-WG] Dynamic Client Registration: policy_uri

policy_uri came down from OpenID Connect Dynamic Client Registraiton 1.0 [1]. It goes: policy_uriOPTIONAL. URL that the Relying Party Client provides to the End-User to read about the how the profile data will be used. The value of this field MUST point to a valid web page. The OpenID Provider SH

[OAUTH-WG] Dynamic Client Registration: application_type

Hi all, with version -18 you guys have added a new meta-data attribute, namely application_type. First, this new attribute is not listed in the IANA consideration section. Second, could you provide a bit of motivation why you need it? What would the authorization server do with that type of info

[OAUTH-WG] Dynamic Client Registration: policy_uri

Hi all, two earlier reviews I have noticed that the policy_uri meta-data attribute is not correctly specified. I offered a suggestion and in both cases my request was ignored. Maybe there is a reason to reject my request but I am uncertain about the relationship with another meta-data attribute,

[OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri

Hi all, in my earlier review I had noted that the semantic of the fields is underspecified, i.e., it is not clear what these fields are used for. In private conversations I was told that an informal reference to a potential use case will be added. I don't see such reference with version -18. Cia

Re: [OAUTH-WG] Dynamic Client Registration: IPR Confirmation

I can confirm that I have no IPR disclosures to make regarding these documents. --Justin /sent from my phone/ On Jul 8, 2014 7:54 AM, Hannes Tschofenig wrote: > > Hi Phil, John, Maciej, Justin, Mike, > > I am working on the shepherd writeup for the dynamic client registration > document and o

[OAUTH-WG] Dynamic Client Registration: IPR Confirmation

Hi Phil, John, Maciej, Justin, Mike, I am working on the shepherd writeup for the dynamic client registration document and one item in the template requires me to indicate whether each document author has confirmed that any and all appropriate IPR disclosures required for full conformance with the

[OAUTH-WG] OAuth 2.0 Dynamic Registration: IANA Consideration Section

I just noticed a minor nit. The registration template for the meta-data attributes says: " Change controller: For Standards Track RFCs, state "IETF". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also