Good to see you are following along with what's happened. On Fri, Mar 11, 2016 at 5:00 PM, Anthony Nadalin <tony...@microsoft.com> wrote:
> Sorry but not true, this started out as “discovery” and now it’s not > > > > *From:* Brian Campbell [mailto:bcampb...@pingidentity.com] > *Sent:* Friday, March 11, 2016 3:59 PM > *To:* Anthony Nadalin <tony...@microsoft.com> > *Cc:* John Bradley <ve7...@ve7jtb.com>; oauth <oauth@ietf.org> > > *Subject:* Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery > > > > That *is* the scope of the current document, which a majority of folks > have agreed with. I was reiterating that the name of the document should > reflect its content, something else that has been widely agreed with. > > > > On Fri, Mar 11, 2016 at 4:24 PM, Anthony Nadalin <tony...@microsoft.com> > wrote: > > 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 > <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fapp.example.com%2f&data=01%7c01%7ctonynad%40microsoft.com%7c4b9bae5dda7a45096b8408d34a031e57%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=fiS8f60ypiXhyM0qVTeql%2b%2bOzH2wbmECQE7J5TtGPQM%3d> > 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 > <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fapp.example.com&data=01%7c01%7ctonynad%40microsoft.com%7c4b9bae5dda7a45096b8408d34a031e57%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=jAsZQeChJ%2bR1lbyBoVKwheIYi3PiWLrq%2bxDLbqU6rxk%3d> > ? > > > > 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 > <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-campbell-oauth-dst4jwt&data=01%7c01%7ctonynad%40microsoft.com%7c4b9bae5dda7a45096b8408d34a031e57%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=STr%2b4krd1hy8h6eHOCLh1PzQaKMUhWlKV2i%2fCL0K1SQ%3d>. > > > > > 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 <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> > <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 > <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-discovery-01&data=01%7c01%7ctonynad%40microsoft.com%7c116eae6bd1b2492d56a508d349545c72%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=w3%2biiaWon81LJCU%2b2mCPRmA%2brECBHgqyRr0OgqiWSHU%3d> > > > > 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 > <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c116eae6bd1b2492d56a508d349545c72%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tNCikmXDBF7ubk%2b%2bzJiXwPB0LIzQXA%2fk%2bqR9m5WgA2k%3d> > > — 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 > <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c116eae6bd1b2492d56a508d349545c72%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tNCikmXDBF7ubk%2b%2bzJiXwPB0LIzQXA%2fk%2bqR9m5WgA2k%3d> > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c116eae6bd1b2492d56a508d349545c72%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tNCikmXDBF7ubk%2b%2bzJiXwPB0LIzQXA%2fk%2bqR9m5WgA2k%3d> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c116eae6bd1b2492d56a508d349545c72%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tNCikmXDBF7ubk%2b%2bzJiXwPB0LIzQXA%2fk%2bqR9m5WgA2k%3d> > > > > > > -- > > Nat Sakimura (=nat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fnat.sakimura.org%2f&data=01%7c01%7ctonynad%40microsoft.com%7c116eae6bd1b2492d56a508d349545c72%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6FVmdN7ad0YzoYKSNF%2fDO%2ffG2EF1haj5aOHiMid6UMI%3d> > @_nat_en > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c4b9bae5dda7a45096b8408d34a031e57%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bKsEVBUXc528yaAMLmycXcL33%2bFJCQrnq9asxRo5He8%3d> > > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c4b9bae5dda7a45096b8408d34a031e57%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bKsEVBUXc528yaAMLmycXcL33%2bFJCQrnq9asxRo5He8%3d> > > > > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
