[OAUTH-WG] Can public clients using code flow have redirect URIs ?

Hi I am a bit confused on whether public clients such as smart phones, etc which work with the authorization code flow can have redirect URIs supported or not. My understanding so far has been that public clients won't have redirect uris (except for them working with Implicit code flows), th

Re: [OAUTH-WG] Can public clients using code flow have redirect URIs ?

Typically native apps on smart phones use the code flow and a redirect_uri with a custom scheme to redirect the browser back to the app with the query encoded code. The native app is a public client as it cannot keep a secret, unless it is using dynamic registration. The ID Nat and I put toget

[OAUTH-WG] Oauth Server to Server was: Dynamic Client Registration Conference Call - Meeting Minutes (22. Aug)

anyone :) ? Begin forwarded message: From: Antonio Sanso mailto:asa...@adobe.com>> Date: August 23, 2013 6:42:18 PM GMT+02:00 To: John Bradley mailto:ve7...@ve7jtb.com>> Cc: Hannes Tschofenig mailto:hannes.tschofe...@gmx.net>>, "oauth@ietf.org WG" mailto:oauth@ietf.org>>

[OAUTH-WG] Refactoring Dynamic Registration

After last week's design team call, at Derek's suggestion, I took time today to refactor the Dynamic Registration draft into two pieces: "core" and "management". The former contains the definition of the Registration Endpoint and the semantics surrounding that, the latter contains the Client Co

[OAUTH-WG] Fwd: New Version Notification for draft-hunt-oauth-v2-user-a4c-01.txt

FYI. Based on feedback from Berlin, Tony and I have revised the draft to include: * Alignment with OpenID Connect (using id_token) * Always returns a JWT * Minimum assertion level on request * Return information about the type of authentication performed Thanks for your input. Phil @independe

Re: [OAUTH-WG] Refactoring Dynamic Registration

Thanks for splitting this and making it simple. It's unclear if the server must send the metadata back in same form/order/ as sent, that is, does client expect to get back only what was sent with what server values will be or can client deal with defaults that the sever sets -Original Mess

Re: [OAUTH-WG] Refactoring Dynamic Registration

A JSON object is not order dependent by definition, so order of elements doesn't matter. In the section on client metadata and the client information response, it's stated that the server can: 1) Override a client's requested values and replace with its own 2) Insert a new field/value that th

Re: [OAUTH-WG] Refactoring Dynamic Registration

Understand all that but does not say what the response will be on an additional parameter that the server does not understand, does the parameter come back with a null, or is the parameter omitted on response ? -Original Message- From: Justin Richer [mailto:jric...@mitre.org] Sent: Tu

Re: [OAUTH-WG] Refactoring Dynamic Registration

If the server does not understand a parameter (and by this, remember, we mean a field in the JSON object, not a query parameter), it can accept it, ignore it, replace it with a default value, or return an error. Think of it in terms of the data model: The client has some model of what informat

Re: [OAUTH-WG] Refactoring Dynamic Registration

This is a better explanation that what is in the current document, as this will become an interop problem that the clients need to deal with and not sure how the client is going to know how to deal with all these permutations, there should be a recommended action. -Original Message- Fro

Re: [OAUTH-WG] Refactoring Dynamic Registration

I believe the http://tools.ietf.org/html/draft-richer-oauth-dyn-reg-management-00 is out of scope for this WG and needs to go to the APPS area since we don't deal with other OAuth management issues -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf

Re: [OAUTH-WG] Refactoring Dynamic Registration

-1, I believe that the management spec is vital for interoperability and well within the scope of this working group, and that the management spec needs to move forward in tandem with the core spec. -- Justin On 08/27/2013 02:41 PM, Anthony Nadalin wrote: I believe the http://tools.ietf.org

Re: [OAUTH-WG] Refactoring Dynamic Registration

OK, please submit text. -- Justin On 08/27/2013 02:38 PM, Anthony Nadalin wrote: This is a better explanation that what is in the current document, as this will become an interop problem that the clients need to deal with and not sure how the client is going to know how to deal with all the

Re: [OAUTH-WG] Refactoring Dynamic Registration

I appreciate that is your opinion. Lets finish splitting the document and agree on what we agree on, then the chairs and others can render a opinion on if http://tools.ietf.org/html/draft-richer-oauth-dyn-reg-management-00 is in scope for this WG.I happen to think it is in scope, and I sus

Re: [OAUTH-WG] Refactoring Dynamic Registration

Unfortunately I haven't been able to attend the design meetings, but I've continued to follow along here with interest. I confess that the core/management split seems a little artificial to me. I can imagine a potential use case for splitting things this way -- even a client that was *staticall

Re: [OAUTH-WG] Refactoring Dynamic Registration

Well, that is just one minor nit and not sure that this is the proper base to start with for the core, I was only trying to understand the intent of the specification. There is the fundamental issue of relationship (endpoint/ API publisher and with whom the client is trying to register with and

Re: [OAUTH-WG] Fwd: New Version Notification for draft-hunt-oauth-v2-user-a4c-01.txt

It is better. We need to talk about what you have done with "min_alv" vs "acr" from connect which is extensible via a IANA registry of Authentication contexts. If it came down to reserving the strings 1 2 3 4 for the ISO29115 reference that could probably be arranged. I don't know that throw

Re: [OAUTH-WG] Fwd: New Version Notification for draft-hunt-oauth-v2-user-a4c-01.txt

See below. Phil @independentid www.independentid.com phil.h...@oracle.com On 2013-08-27, at 4:27 PM, John Bradley wrote: > It is better. We need to talk about what you have done with "min_alv" vs > "acr" from connect which is extensible via a IANA registry of Authentication > contexts

Re: [OAUTH-WG] Fwd: New Version Notification for draft-hunt-oauth-v2-user-a4c-01.txt

I thought you wanted to keep the profile endpoint (user_info) out of this. Once you have a user-info type endpoint you get into defining scopes for claims and I thought Tony wanted to avoid this and have it be only session authentication. Connect publishes its idp config in the .well-known d

Re: [OAUTH-WG] Fwd: New Version Notification for draft-hunt-oauth-v2-user-a4c-01.txt

I'm concerned that the current "alv" and "min_alv" text wouldn't survive IESG review since depending up NIST SP-800-63-2 is US-centric. The point of OpenID Connect "acr" (authentication context class reference) claim using RFC6711 is that the authentication context values used are international

Re: [OAUTH-WG] Fwd: New Version Notification for draft-hunt-oauth-v2-user-a4c-01.txt

John, I do not what to do anything to specify the profile endpoint. The big problem is there are already many APIs -- user_info is but one. The problems in the IETF OAuth space, is that the URL the client "thinks" is the authenticated user is not guaranteed to be the user. For example, the c

Re: [OAUTH-WG] Fwd: New Version Notification for draft-hunt-oauth-v2-user-a4c-01.txt

The authenticated user is the "sub" scoped to "iss" not the profile URL. A profile URL is informational and may change for the user.I think making it a structured element describing the API is going beyond the "Simple" I was assuming that the profile URI would be under the control of the A

Re: [OAUTH-WG] Fwd: New Version Notification for draft-hunt-oauth-v2-user-a4c-01.txt

So these are not authentication context. It does more harm than good to have an extensible IANA registry of values that have no discernable meaning, with the ISO 29115 values you can go an acutually understand the values and have something to potentially interop on From: oauth-boun...@ietf.org