I will put that forward in an alternate draft. Phil
> On Mar 12, 2016, at 08:28, Mike Jones <michael.jo...@microsoft.com> wrote: > > The AS metadata format is a necessary part of discovery. No, it doesn’t > accomplish every possible aspect of discovery – nor was it ever intended to. > I’ve consistently encouraged Phil and others to write down additional aspects > of discovery in specifications that build upon this one so that the working > group and implementers can evaluate them. > > Since we’re chartered to do discovery and this is part of discovery, no > rechartering is needed either for the current specification or for new > specifications performing additional discovery tasks. > > -- Mike > > From: Anthony Nadalin > Sent: Saturday, March 12, 2016 8:20 AM > To: Mike Jones <michael.jo...@microsoft.com>; Brian Campbell > <bcampb...@pingidentity.com>; John Bradley <ve7...@ve7jtb.com> > Cc: oauth <oauth@ietf.org> > Subject: RE: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery > > We agreed upon a discovery specification that the WG would work on, we did > not agree upon what this has turned out to actually be, so at the minimum the > chairs should call for adoption of a Authorization Server Metadata > specification and we can continue to work on a Discovery specification > > From: Mike Jones > Sent: Saturday, March 12, 2016 8:06 AM > To: Anthony Nadalin <tony...@microsoft.com>; Brian Campbell > <bcampb...@pingidentity.com>; John Bradley <ve7...@ve7jtb.com> > Cc: oauth <oauth@ietf.org> > Subject: RE: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery > > The draft enables easy configuration of OAuth clients with an AS. For > instance, the Microsoft “ADAL” OAuth client software uses AS metadata in this > format as an input at client configuration time. > > As a side benefit, having this standard AS metadata format and returning the > issuer URL per the Mix-Up Mitigation draft will also enable clients to > validate that they are using a consistent set of AS endpoints and > information. But even without the mitigation benefits, the client > configuration benefit is the primary reason for the specification. > > -- Mike > > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin > Sent: Friday, March 11, 2016 3:25 PM > To: Brian Campbell <bcampb...@pingidentity.com>; John Bradley > <ve7...@ve7jtb.com> > Cc: oauth <oauth@ietf.org> > Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery > > Disagree, what purpose is this activity solving then, it was being pushed as > what was need to solve the Mix-up, but that is not true. So now you are > suggesting a change in scope and not dealing with discovery. > > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell > Sent: Friday, March 11, 2016 3:11 PM > To: John Bradley <ve7...@ve7jtb.com> > Cc: oauth <oauth@ietf.org> > Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery > > I tend to agree with John that addressing the concerns Phil raises should be > part of (extension to) the core protocol. And that those kinds of concerns > don't manifest in the way OAuth is typically deployed now. > > The hopefully soon to be named "OAuth 2.0 Authorization Server Metadata" > should keep it's scope to the publishing of authorization server metadata. > The act of doing discovery is beyond its scope and so is trying to prevent a > client from presenting a token to someplace it shouldn't. > > > On Fri, Mar 11, 2016 at 9:08 AM, John Bradley <ve7...@ve7jtb.com> wrote: > Inline > On Mar 11, 2016, at 12:13 PM, Phil Hunt (IDM) <phil.h...@oracle.com> wrote: > > John > > In many case all the AS has to check is the domain name component to check > for mitm. > > POP and the other solns are dramatically more complex than a simple check. > > I was proposing ding that check at the authorization endpoint or token > endpoint as part of AT issuance. > > It is up to the AS how much of the path to validate and or put in the aud or > dst. > > > > I see it as part of the discovery(bad name aside) problem because we > discussed that if a client finds app.example.com how do we ensure it gets a > complete set of oauth endpoints as a valid set of endpoints--that a hacker > has not inserted one of their own endpoints. The most important endpoint to > get right is ensuring the resource server (and optionally the path) is the > correct one. We can't really define resource discovery but we can validate it > to some degree. > > I think it is part of core protocol security and should/must not require > discovery. > > What is app.example.com ? > > If it is the resource then the client would be preconfigured for it’s AS out > of band or optionally would do discovery on the issuer uri that you admit > needs to be configured out of band some way (note discovery is optional) > > In the AS meta-data draft it would do a get on a well known file that would > have configuration for the AS, but not the RS, though some API may optionally > list a API endpoint like connect has. > > The client then makes a authorization request (after registering out of band > or dynamically). > As part of the authorization request for implicit it could provide the > aud/dst that it wants the token for. > If that is not sent then the aud/dst are implicit in the scopes. > > The client gets back a AT with a list of scopes granted, aud/dst allowed and > time to live for the token (one extra thing returned) > > This doesn’t require any discovery (yes there is a optional AS meta-data > discovery but not required) > > I prefer to fix the RS man in the middle issue as part of the protocol and > not part of discovery that should remain optional. > > I honestly don’t quite know how the client learns about this bad RS and > starts talking to it, so this may be a solution to a problem that doesn’t yet > exist. The one place this is posable is if the registration for the client > is compromised. However we are discussing other mitigations for that that > also explicitly do not require discovery. > > John B. > > > > I am not stuck on webfinger or well-known. Because this is config maybe it > should be an oauth endpoint. > > Phil > > On Mar 11, 2016, at 06:51, John Bradley <ve7...@ve7jtb.com> wrote: > > I think Phil is proposing something different. Should the client send a > token from this AS to that RS. > > His goal is to prevent man in the middle attacks where a bad RS gets a AT > that is audianced to/accepted by another RS. > > That is separate from the question of if a RS accepts tokens from a good AS. > A bad AS would always say yes. > > We need to be careful of what if anything the RS provides to the client as > meta-data without validation. > > Currently the client can provide a list of scopes required to get access. I > personally feel it would be useful to also include in the unauthenticated > error response an indication of what API the resource supports. Say “scim2” > as an example. I don’t think adding that is however a high priority as most > if all clients know what API they expect. It might be useful if at some > point in the future if a client were to be given a RS URI it could check to > see if it is a protocol that it supports before bothering with OAuth. I > expect that a lot of people will want that left to the API definition. I > think we can talk about it but rate this low priority. > > I agree that the RS giving out a list of AS that it trusts is a generally bad > idea. I hope that is not on the table. > > I don’t think that preventing a client from sending a token to the wrong RS > is part of a AS meta-data discovery problem. > > I do however think that it is important. > > We have been discussing this as a separate problem to AS meta-data discovery > where the endpoints of the AS and it’s configuration are discovery. Sorry > for perhaps stating the obvious, but the RS is explicitly not part of the AS > in OAuth 2. Starting in WAP that was a core principal. > > So we have a number of options to address the RS token leakage via MiTM > attacks. > > 1) PoP bound tokens. If they are bound to the TLS channel by mutual TLS or > Token binding they cannot be replayed. Signed messages where the signing > covers the RS Host and path components, also would work. > > 2) Have the AS audience restrict the resources the AT is good at. (AT should > be doing that now) > In the token response include the list of audience/s the token is presentable > at. The client would throw an error if the RS it intends to send the token > to is not on the list. The RS the token is good at might change based on > scopes, client_id and resource owner. This is the place where all of that > comes together. In some cases the RS and AS might not have a > pre-established relationship. The client should send the RS base URI to the > AS as part of the request. The AS can use that to audience restrict the AT > and issue the AT or refuse to issue the AT based on policy. > It can also use the audience in the request to down audience the AT if the > default is to have multiple audiences. We may want to use a term other > than audience for this like resource or destination. It is a audience but > that term might confuse people with AT. > > We did talk about breaking audience out of POP key distribution, and Brian > Campbell did a draft > https://tools.ietf.org/html/draft-campbell-oauth-dst4jwt. > > To do this we could take dst4jwt and add another spec that adds a new dst > parameter to the token and authorization endpoints requests That would be a > space separated list of dst values. and in the response from the token > endpoint would be a JSON array of dst values. > > 3) Have the AS always return all the list of all RS the token can be used at > (basically Nat's link relationship proposal). It needs a way to handle > down destinationing of AT and to allow for un-configured RS that it might > issue a token for. So could be combined with dst from 2. Basically > returning the acceptable destinations as link headers vs JS in the response > is mostly a style issue that other people can bike shed. > > > 4) Trying to add all the RS to the AS discovery document. This seems > impractical as there would be multiple protocols and doesn’t address > un-configured RS. > > 5) Some new AS endpoint that the client could introspect the RS URI and get > back metadata about if the client should send tokens there. > A couple of problems with this. The first is that it would not support > un-configured RS unless you add dst to the token and authorization endpoints. > The other is that the introspection endpoint doesn’t have the context of > the RO and client_id unless you also pass the code/RT and client_id, and > probably client credentials. Basically this is trying to introspect the AT > to determine the audiance/dst. By the time you build a new introspection > endpoint securely it is going to look like the token endpoint with a bit more > meta data about the token beyond expiry and scopes. > > > I think we should go a head with the renamed "OAuth 2.0 Authorization Server > Discovery Metadata” > I am also fine with making the default document 'openid-configuration’ as > long as we allow for protocol specific variation so that SCIM2 could define a > file name. If people want we could do a API to file name registry so that > protocol specific ones can be defined. > > We are all-ready working on option 1 to secure AT, we need a spec like I > propose in 2 for bearer tokens. We can add one request parameter and a bit > more token meta-data to the token response and that takes care of the > problem. Honestly we probably should have separated scope and destination > in the first place and returned both dst and scope in the response all along, > so this is update that is consistent with the eisting architecture of OAuth 2. > > Lets keep the two issues separate. > > John B. > > > > > On Mar 11, 2016, at 12:07 AM, Anthony Nadalin <tony...@microsoft.com> wrote: > > The relationship between AS and RS need to be scoped to “does this RS accept > tokens from this AS” as a list is too much information that could be used in > the wrong way > > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Nat Sakimura > Sent: Thursday, March 10, 2016 6:25 PM > To: Phil Hunt (IDM) <phil.h...@oracle.com> > Cc: oauth <oauth@ietf.org> > Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery > > Phil, > > Right. So what my conditional approvals (11 conditions in total) said was to > drop the word "discovery" from everywhere. This is not a discovery spec. This > is a configuration lookup spec as you correctly points out. So, I am with you > here. > > Also, my 2nd conditiion is essentially saying to drop section 3. > > One thing that I overlooked and am with you is that we need to be able to > express the AS-RS relationships. I have been preaching this in the other > thread for so many times as you know so I thought I pointed it out, but > missed apparently in my previous comment. So, I would add my 12th condition: > > 12. A way to express a list of valid RSs for this AS needs to be added to > section 2. > > Best, > > Nat > > 2016-03-11 2:09 GMT+09:00 Phil Hunt (IDM) <phil.h...@oracle.com>: > I strongly oppose. 2 major issues. > > This is not service discovery this is configuration lookup. The client must > have already discovered the oauth issuer uri and the resource uri. > > The objective was to provide a method to ensure the client has a valid set of > endpoints to prevent mitm of endpoints like the token endpoint to the > resource server. > > The draft does not address the issue of a client being given a bad endpoint > for an rs. What we end up with is a promiscuous authz service giving out > tokens to an unwitting client. > > Phil > > On Mar 10, 2016, at 08:06, Vladimir Dzhuvinov <vladi...@connect2id.com> wrote: > > +1 to move forward with these > > On 10/03/16 17:35, Brian Campbell wrote: > +1 > > On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg <roland.hedb...@umu.se> > wrote: > > I support this document being moved forward with these two changes: > > - change name to “OAuth 2.0 Authorization Server Discovery Metadata” as > proposed by Brian and > - use the URI path suffix ’oauth-authorization-server’ instead of > ’openid-configuration’ as proposed by Justin. > > 18 feb 2016 kl. 14:40 skrev Hannes Tschofenig <hannes.tschofe...@gmx.net > : > > Hi all, > > This is a Last Call for comments on the OAuth 2.0 Discovery > specification: > https://tools.ietf.org/html/draft-ietf-oauth-discovery-01 > > Since this document was only adopted recently we are running this last > call for **3 weeks**. > > Please have your comments in no later than March 10th. > > Ciao > Hannes & Derek > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > — Roland > > ”Everybody should be quiet near a little stream and listen." > >From ’Open House for Butterflies’ by Ruth Krauss > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
