Re: [OAUTH-WG] OAuth 2.0 Discovery Location

man.se>] *Sent:* Saturday, February 27, 2016 6:47 AM *To:* Mike Jones mailto:michael.jo...@microsoft.com>> *Cc:* Vladimir Dzhuvinov mailto:vladi...@connect2id.com>>; oauth@ietf.org <mailto:oauth@ietf.org> *Subject:* Re: [OAUTH-WG] OAuth 2.0 Discovery Lo

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

On Mon, Feb 29, 2016 at 11:35 PM Brian Campbell wrote: > +1 for "OAuth 2.0 Authorization Server Discovery” from those two options. > > But what about "OAuth 2.0 Authorization Server Metadata”? > > The document in its current scope (which I agree with, BTW) isn't really > about discovery so much a

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

tman [mailto:sam...@erdtman.se] >> *Sent:* Saturday, February 27, 2016 6:47 AM >> *To:* Mike Jones >> *Cc:* Vladimir Dzhuvinov ; oauth@ietf.org >> >> *Subject:* Re: [OAUTH-WG] OAuth 2.0 Discovery Location >> >> >> >> +1 for “OAuth 2.0 Authoriz

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

+1 > 29 feb. 2016 kl. 15:41 skrev Brian Campbell : > > +1 > > On Fri, Feb 19, 2016 at 9:28 PM, Vladimir Dzhuvinov > wrote: > +1 > > On 19/02/16 23:59, Justin Richer wrote: > > The newly-trimmed OAuth Discovery document is helpful and moving in the > > right d

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

+1 On Fri, Feb 19, 2016 at 9:28 PM, Vladimir Dzhuvinov wrote: > +1 > > On 19/02/16 23:59, Justin Richer wrote: > > The newly-trimmed OAuth Discovery document is helpful and moving in the > right direction. It does, however, still have too many vestiges of its > OpenID Connect origins. One issue

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

* Vladimir Dzhuvinov ; oauth@ietf.org > > *Subject:* Re: [OAUTH-WG] OAuth 2.0 Discovery Location > > > > +1 for “OAuth 2.0 Authorization Server Discovery” > > > > //Samuel > > > > On Thu, Feb 25, 2016 at 8:10 PM, Mike Jones > wrote: > > Thanks f

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

: Mike Jones Cc: Vladimir Dzhuvinov ; oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location To clarify…. I am not suggesting that we need a resource discovery mechanism. What I am suggesting is much simpler. I propose that the authorization confirm that the endpoint that the client

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

invention, authorization server discovery does not. > > -- Mike >   <> > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Vladimir Dzhuvinov > Sent: Saturday, February 27, 2016 10:33 AM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Loc

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location On 27/02/16 20:10, Phil Hunt wrote: The name change seems appropriate given that the WG members have decided not to address the issue of resource discovery as part of this specification. If the consensus is to limit the scope of the

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

AS. 6750 is about the RS. The discovery >> document is about the AS. We don’t yet have a specification or existing >> practice for RS discovery, which would be the 6750 analogy. >> >> >> >> In summary, which title do people prefer? >> >> · “OAuth 2.0 Discovery” >> >> · “OAuth 2.0 Authorization

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

-- Mike > >   <> > From: OAuth [mailto:oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>] > On Behalf Of Vladimir Dzhuvinov > Sent: Thursday, February 25, 2016 12:59 AM > To: oauth@ietf.org <mailto:oauth@ietf.org>

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

, -- Mike From: Samuel Erdtman [mailto:sam...@erdtman.se] Sent: Saturday, February 27, 2016 6:47 AM To: Mike Jones Cc: Vladimir Dzhuvinov ; oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location +1 for “OAuth 2.0 Authorization Server Discovery” //Samuel

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

ver Discovery” > > > > -- Mike > > > > *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Vladimir > Dzhuvinov > *Sent:* Thursday, February 25, 2016 12:59 AM > *To:* oauth@ietf.org > >

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

+1 Sent by MailWise – See your emails as clean, short chats. Originalnachricht Betreff: Re: [OAUTH-WG] OAuth 2.0 Discovery Location Von: Justin Richer An: George Fletcher Cc: "" >+1 for “OAuth 2.0 Authorization Server Discovery” > > — Justin > >>

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

e >>   <> >> From: OAuth [mailto:oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>] >> On Behalf Of Vladimir Dzhuvinov >> Sent: Thursday, February 25, 2016 12:59 AM >> To: oauth@ietf.org <mailto:oauth@ietf.org> >> Subject: Re: [OAUTH-WG]

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

lf Of *George Fletcher *Sent:* Friday, 26 February 2016 2:28 AM *To:* Vladimir Dzhuvinov mailto:vladi...@connect2id.com>>; oauth@ietf.org <mailto:oauth@ietf.org> *Subject:* Re: [OAUTH-WG] OAuth 2.0 Discovery Location That said, I'm not against th

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

>> >> >> -- >> >> James Manger >> >> >> >> >> >> >> >> From: OAuth [mailto:oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>] >> On Behalf Of George Fletcher >> Sent: Friday, 2

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

ilto:oauth-boun...@ietf.org>] > On Behalf Of George Fletcher > Sent: Friday, 26 February 2016 2:28 AM > To: Vladimir Dzhuvinov <mailto:vladi...@connect2id.com>>; oauth@ietf.org <mailto:oauth@ietf.org> > > Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location >

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

t; James Manger > > > > > > > > *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *George > Fletcher > *Sent:* Friday, 26 February 2016 2:28 AM > *To:* Vladimir Dzhuvinov ; oauth@ietf.org > > > *Subject:* Re: [OAUTH-WG] OAuth 2.0 Discovery Location > &g

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

.@gmail.com> Cc: <mailto:oauth@ietf.org> <mailto:oauth@ietf.org> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture. What

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

-- Mike >   <> > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Vladimir Dzhuvinov > Sent: Thursday, February 25, 2016 12:59 AM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location > > I

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

From: Mike Jones [mailto:michael.jo...@microsoft.com] Sent: Thursday, February 25, 2016 2:10 PM To: Vladimir Dzhuvinov ; oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location Thanks for your thoughts, Vladimir. I’m increasingly inclined to accept your suggestion to change the

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

:* Re: [OAUTH-WG] OAuth 2.0 Discovery Location In OIDC the discovery doc is of great utility to developers and integrators. Developers also tend to find it a more accurate and complete description of how to set up a client for a particular deployment, compared to traditional online docs, which

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

e From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com] Sent: Wednesday, February 24, 2016 3:52 PM To: Mike Jones Cc: <mailto:oauth@ietf.org> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location Mike Take a look at the assumptions you are making. You seem to be assuming app

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

On Thu, Feb 25, 2016 at 4:25 PM George Fletcher wrote: > Interesting... this is not at all my current experience:) If a RS goes > from v2 of it's API to v3 and that RS uses the current standard of putting > a "v2" or"v3" in it's API path... then a token issued for v2 of the API can > not be sent

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

m] Sent: Thursday, February 25, 2016 10:17 AM To: Donald F. Coffin ; Vladimir Dzhuvinov ; oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location Interesting. Is there a link that I can download your spec etc. ? I have not much preference over the actual endpoint link or the web o

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

en >>>> response beside the access_token field. >>> +1 >>> >>> This will appear more consistent with the current experience, and >>> OAuth does allow the token response JSON object to be extended with >>> additional members (as it's done in OpenID Con

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

tional members (as it's done in OpenID Connect already). Cheers, Vladimir -- James Manger From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of George Fletcher Sent: Thursday, 25 February 2016 6:17 AM To: Phil Hunt; Nat Sakimura Cc: Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location I

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

e Fletcher Sent: Thursday, 25 February 2016 6:17 AM To: Phil Hunt; Nat Sakimura Cc: Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture.

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

woody, GA 30338-8221 > > > > Phone: (949) 636-8571 > > Email: donald.cof...@reminetworks.com > > > > *From:* Vladimir Dzhuvinov [mailto:vladi...@connect2id.com] > *Sent:* Thursday, February 25, 2016 2:23 AM > *To:* oauth@ietf.org > > > *Subject:

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

; Nat Sakimura *Cc:* *Subject:* Re: [OAUTH-WG] OAuth 2.0 Discovery Location I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture. What if a RS moves to a new endpoint? All clients would

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

25, 2016 2:23 AM To: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location On 25/02/16 09:02, Manger, James wrote: I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture T

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

f general applicability. >> >> -- Mike >> >> From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com] >> Sent: Wednesday, February 24, 2016 3:52 PM >> To: Mike Jones >> Cc: >> Subject

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

lready). Cheers, Vladimir > -- > James Manger > > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of George Fletcher > Sent: Thursday, 25 February 2016 6:17 AM > To: Phil Hunt ; Nat Sakimura > Cc: > Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location > > I

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

ken field. -- James Manger From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of George Fletcher Sent: Thursday, 25 February 2016 6:17 AM To: Phil Hunt ; Nat Sakimura Cc: Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location I'm concerned that forcing the AS to know about all RS

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

register those that are of general applicability. > > -- Mike > > From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com] > Sent: Wednesday, February 24, 2016 3:52 PM > To: Mike Jones > Cc: > Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

can register those that are of general applicability. -- Mike From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com] Sent: Wednesday, February 24, 2016 3:52 PM To: Mike Jones Cc: Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

e.com] > Sent: Wednesday, February 24, 2016 2:13 PM > To: Mike Jones > Cc: > Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location > > Yup. And because there many relations the client mist be able to discover it. > The client does not know if the res server is legit. > &

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

:25 PM To: Mike Jones Cc: mailto:oauth@ietf.org>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location Where is the profile endpoint (oidc's resource server) published? (For the non OIDC people on the list). Phil On Feb 24, 2016, at 13:09, Mike Jones mailto:michael.jo...@microsoft.co

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

> Sent: Wednesday, February 24, 2016 1:25 PM > To: Mike Jones > Cc: > Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location > > Where is the profile endpoint (oidc's resource server) published? (For the > non OIDC people on the list). > > Phil > > O

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

: Mike Jones Cc: Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location Where is the profile endpoint (oidc's resource server) published? (For the non OIDC people on the list). Phil On Feb 24, 2016, at 13:09, Mike Jones mailto:michael.jo...@microsoft.com>> wrote: To the extent that ge

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

nce at this time. > > Phil > > On Feb 24, 2016, at 10:25, Anthony Nadalin wrote: > > Sure there is, it is as you have now made it far easier and the security > considerations does not even address this > > From: Mike Jones > Sent: Wednesday, February 24, 201

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

-- Mike From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com] Sent: Wednesday, February 24, 2016 12:45 PM To: Anthony Nadalin Cc: Mike Jones ; Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location Mike Publishing on dev pages does not work for software (esp o

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

> To: Anthony Nadalin > Cc: > Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location > > As we’d discussed in person, there’s no effective security difference between > discovery information being published in an ad-hoc fashion on developer pages > and it being published in

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture. What if a RS moves to a new endpoint? All clients would be required to get new tokens (if I understand correctly). And the RS move would have to coordi

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

. -- Mike From: Anthony Nadalin Sent: Wednesday, February 24, 2016 10:26 AM To: Mike Jones Cc: Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location Sure there is, it is as you have now made it far easier and the security considerations

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Sure there is, it is as you have now made it far easier and the security considerations does not even address this From: Mike Jones Sent: Wednesday, February 24, 2016 10:22 AM To: Anthony Nadalin Cc: Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location As we’d discussed in person, there’s no

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

. -- Mike From: Anthony Nadalin Sent: Wednesday, February 24, 2016 10:01 AM To: Mike Jones ; Phil Hunt (IDM) ; Nat Sakimura Cc: Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location > The point of the WGLC is to finish standardizing the core discovery > functionality

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

tf.org] On Behalf Of Mike Jones Sent: Wednesday, February 24, 2016 9:54 AM To: Phil Hunt (IDM) ; Nat Sakimura Cc: Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location The point of the WGLC is to finish standardizing the core discovery functionality that’s already widely deployed. None of Nat o

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

mechanisms will need. -- Mike From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt (IDM) Sent: Wednesday, February 24, 2016 8:39 AM To: Nat Sakimura Cc: Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location I am suggesting

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

I am suggesting that part of the discovery solution has to be the client indicating what resource endpoint it wants the oauth configuration data for. So if res.example.evil.com is not a valid resource endpoint for as.example.com the authz discovery should fail in some way (eg return nothing).

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Hi Phil, Are you suggesting that the AS metadata should include the RS URIs? Currently, it does not, but it can be done, I guess. The way oauth-meta works is that 1. RS tells the client where the AS is. 2. AS tells the client which RS endpoints the token can be used. Even if there is a bad AS w

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Right. As there can be multiple WWW-authenticate header, it is doable that way. Maybe that's better in this respect, though it becomes a bit different than other metadata. Alternatively, the scope can be added as a parameter in the auri Web Link header. Good things about the Link Header is that yo

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Hi Nat, On Wed, Feb 24, 2016 at 12:54 PM Nat Sakimura wrote: > > 2016年2月22日(月) 18:44 Thomas Broyer : > > >> (well, except if there are several ASs each with different scopes; sounds >> like an edge-case to me though; maybe RFC6750 should instead be updated >> with such a parameter such that an R

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Nat, I’m not sure that having the resource server tell the client where its authorization server is secure by itself. The relationship between the Authorization Server and the Resource server need to be bound together in one of the discovery endpoints (the resource and/or the oauth service disc

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Hi Thomas, inline: 2016年2月22日(月) 18:44 Thomas Broyer : > Couldn't the document only describe the metadata? > I quite like the idea of draft-sakimura-oauth-meta if you really want to > do discovery, and leave it open to implementers / to other specs to define > a .well-known URL for "auto-configu

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

I think you can really do both parts in the document without harm. Specifying a ".well-known" location doesn't preclude you from including the same metadata elsewhere as well, such as with oauth-meta or with a service-specific discovery document (like openid-configuration). But it would be nice

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Couldn't the document only describe the metadata? I quite like the idea of draft-sakimura-oauth-meta if you really want to do discovery, and leave it open to implementers / to other specs to define a .well-known URL for "auto-configuration". The metadata described here would then either be used as-

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Hi, I agree that the user of “/.well-known/openid-configuration” is confusing and that it would be preferable with something else, but it is written as an example not necessarily a default. However to use “/.well-known/oauth-authorization-server” might be problematic if as written different appli

[OAUTH-WG] OAuth 2.0 Discovery Location

Hi, Here coms some review comments, In general I think this is a good document. //Samuel 2. Authorization Server Metadata token_endpoint, I would prefer if the requiredness of this parameter was put in the beginning instead of the end as with the other parameters. jwks_uri, I would like to c

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

+1 On 19/02/16 23:59, Justin Richer wrote: > The newly-trimmed OAuth Discovery document is helpful and moving in the right > direction. It does, however, still have too many vestiges of its OpenID > Connect origins. One issue in particular still really bothers me: the use of > “/.well-known/ope

[OAUTH-WG] OAuth 2.0 Discovery Location

The newly-trimmed OAuth Discovery document is helpful and moving in the right direction. It does, however, still have too many vestiges of its OpenID Connect origins. One issue in particular still really bothers me: the use of “/.well-known/openid-configuration” in the discovery portion. Is this