[OAUTH-WG] I-D Action: draft-ietf-oauth-discovery-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol of the IETF. Title : OAuth 2.0 Discovery Authors : Michael B. Jones Nat Sakimura

[OAUTH-WG] Initial OAuth working group Discovery specification

We have created the initial working group version of OAuth Discovery based on draft-jones-oauth-discovery-01, with no normative changes. The specification is available at: * http://tools.ietf.org/html/draft-ietf-oauth-discovery-00 An HTML-formatted version is also available at: * h

[OAUTH-WG] Missing response_type with implicit and code flows on the same path

Hi OAuth2 spec recommends how to deal with a missing response_type, set an error as a query or fragment parameter, depending on whether it is the authorization code or implicit flow and redirect. This implies that authorization code and implicit handlers listen on different paths, for exampl

Re: [OAUTH-WG] Missing response_type with implicit and code flows on the same path

Hi Sergey, Yes, HTTP 400 is one way to handle a missing response_type with a "universal" authz endpoint. Or, you could encode the error in the query string as well as the fragment, and redirect back to the client. Vladimir On 09/02/16 16:39, Sergey Beryozkin wrote: > Hi > > OAuth2 spec recomme

Re: [OAUTH-WG] Missing response_type with implicit and code flows on the same path

Hi Vladimir Thanks for the response, On 09/02/16 16:09, Vladimir Dzhuvinov wrote: Hi Sergey, Yes, HTTP 400 is one way to handle a missing response_type with a "universal" authz endpoint. Indeed, looks like it makes sense Or, you could encode the error in the query string as well as the fragm

Re: [OAUTH-WG] Initial OAuth working group Discovery specification

Mike, thanks for putting this up. I would like to propose for two changes that have been brought up before: 1) The wholesale removal of section 2, Webfinger lookup. 2) The changing of "/.well-known/openid-configuration” to "/.well-known/oauth-authorization-server” or something else not openid

Re: [OAUTH-WG] Initial OAuth working group Discovery specification

If we keep webfinger I don’t think that having a generic OAuth rel makes sense. It should be up to each API/Protocol to define it’s own rel value like Connect has done. It is not reasonable to think that a persons ID provider is going to be the same as the one for calendaring or photo sharing

Re: [OAUTH-WG] Initial OAuth working group Discovery specification

Webfinger without a rel= doesn’t make much sense for us to define, does it? What output value is the client going to look for in the response, then? I’m with John that we should let applications define their own rel= values and therefore leave webfinger out entirely. I don’t buy the historical

Re: [OAUTH-WG] Initial OAuth working group Discovery specification

Another example is to look at scim discovery(in contrast with connect). When asked separately the answers may be different. Asking what is the oauth server for scim is yet another relation. So may be we need a scheme for oauth where query is rs:someval and optionally an acnt value to. For e

Re: [OAUTH-WG] Initial OAuth working group Discovery specification

You would define a rel uri for SCIM. The SCIM entry can have sub properties if it supported more than one auth type, or you could have a SCIM discovery document that the URI points to. There are probably multiple ways to do it. I don’t think trying to have a oauth rel and then sub types is g

Re: [OAUTH-WG] Initial OAuth working group Discovery specification

The rel for scim returns the endpoint for scim. The rel for oauth returns endpoints for oauth. The query lets the client say i want the endpoint for oauth used for scim. I suppose you could reverse it but then we'll have oauth discovery happening in different ways across many different specs

Re: [OAUTH-WG] Initial OAuth working group Discovery specification

Please don’t break the webfinger RFC. If you search for SCIM you can have additional properties returned as part of the entry, but you only search for one thing. Webfinger is designed to be very simple to implement. In general you just get back the whole document with all the rel. The query

Re: [OAUTH-WG] Initial OAuth working group Discovery specification

Huh? Our proposals are the opposite of one-another. In your proposal you have people querying scim to get oauth. I’m saying you query rel=scim to get information about SCIM. Querying rel=SCIM and receiving OAuth seems bass- ackwards does it not? Further, having rel=oauth lets us define one

Re: [OAUTH-WG] Initial OAuth working group Discovery specification

Have a look at https://tools.ietf.org/html/rfc7033 The way to do what you want would mean having multiple array objects with the same rel and somehow differentiating them via properties. I think that is going to be more complicated for clients to parse. I t

Re: [OAUTH-WG] Initial OAuth working group Discovery specification

John, I am following 7033. The rel parameter is not the query it is the sub set of the resource you want information about. There is nothing complex here. In most cases this would be responded to by a simple transformation pattern. Correcting my previous example (but showing it in easy to rea

Re: [OAUTH-WG] Initial OAuth working group Discovery specification

OK I was talking about discovering user services via webfinger, (The way connect uses it and most other things) and you are talking about using it to discover things about a server. Your first example had ph...@example.com as the account you were querying, and that seemed like a user discovery

Re: [OAUTH-WG] Initial OAuth working group Discovery specification

+1 to John’s point. Webfinger is, as designed, about doing per-user service discovery. Let’s keep the OAuth service discovery away from that. What does it mean to find the OAuth server for a user, anyway? Without the context of a resource protocol, I don’t think it does. If you already have the