Mike, there is no need to rush standardizing the metadata since there are still obvious issues with discovery or what one thinks discovery should be and should not be. This is also not the OpenID Foundation, this group should not be constrained by what OpenID has done but we should be informed. Some companies/individuals may have taken what was used by OpenID and used that as Oauth Discovery but once again we should not be restrained in what is technically the best choice because OpenID did it a certain way, it may be that OpenID did it the best way but lets not try to force the decision bases upon OpenID Certification.
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Sunday, March 13, 2016 10:29 PM To: Phil Hunt <phil.h...@oracle.com> Cc: oauth <oauth@ietf.org> Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt Thanks for posting this, Phil. It provides a concrete example of a way that protected resource discovery could be added to authorization server metadata discovery, and as such, should provide useful input for working group discussions on this topic. It’s always great when someone takes the time to write an actual draft that can be examined and implemented, and I appreciate you doing that. The content of your draft points out that there appears to be complete agreement on what the authorization server metadata format should be, which is great! I’ll note that Section 3 of draft-hunt-oauth-bound-config-00 titled “Authorization Server Metadata” is an exact copy of Section 2 of draft-ietf-oauth-discovery-01 (with the same title), modulo applying a correction suggested by the working group. To me this suggests that the authorization server metadata definitions in draft-ietf-oauth-discovery (which is now the whole normative content of the draft) are clearly ready for standardization, since even your alternative proposal includes them verbatim. Reading your draft, the problem I have with it is that you are returning the AS metadata only as a WebFinger response, rather than as an https-protected resource published by the authorization server. The choice to only return this via WebFinger makes your draft incompatible with most deployed implementations of OAuth metadata, including the 22 implementations using it listed at http://openid.net/certification/<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fopenid.net%2fcertification%2f&data=01%7c01%7ctonynad%40microsoft.com%7c58284b200e8f43930bf708d34bc98ca0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=0545jB5xOjrJF0Kre7BXKgdGBR6wZSTcHVEwftxjoUQ%3d> (see the “OP Config” column in the table) and OAuth 2.0 libraries such as Microsoft’s “ADAL” library, which uses the metadata path for client configuration. Without having ASs provide the metadata as an https-protected resource, implementations such as ADAL can’t use it for client configuration as the currently do. Therefore, I would request that you make these minor revisions to your draft and republish, so as to provide a unified way forward that is compatible with all known existing OAuth Discovery deployments: 1. Modify your section 2 “Authorization Server WebFinger Discovery” to have the WebFinger request return the issuer identifier for the AS as the “WebFinger “rel” value, rather than returning the metadata values by value as the “properties” value. 2. Reference the metadata definitions from Section 2 of draft-ietf-oauth-discovery, rather than duplicating them in your Section 3. That would have the advantage of paring your draft down to only the new things that it proposes, enabling them to be more clearly understood and evaluated on their own merits. I look forward to the discussions of ways of performing additional kinds of OAuth discovery, and consider your draft a valuable input to those discussions. Best wishes, -- Mike From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley Sent: Sunday, March 13, 2016 6:45 PM To: Phil Hunt <phil.h...@oracle.com<mailto:phil.h...@oracle.com>> Cc: oauth <oauth@ietf.org<mailto:oauth@ietf.org>> Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt As I have told Phil off list. Discovery is the wrong place to try and provide security against man in the middle attacks on the RS. This requires the client to know what the RS URI is before retrieving the information on the AS Configuration. The proposal Mike and I have been working on requires the client to have a notion of what API it is looking for and retrieve the .well-known file for that API from the issuer. That allows a protocol like Connect to register its own config file that can point to the RS. If the API specific well known is not available the client can try the default oauth-server one. That then allows us to deal with restricting where AT are presented as part of the protocol rather then dragging discovery in as a requirement. In my opinion the resource the token is targeted to should be separated from the scope and returned as part of the meta-data about the AT along with scopes granted and expiry time. We should also have a input parameter for resources so that a client can restrict tokens issued to a subset of the ones granted by the refresh token. It would then also be possible to ask a AS for a token for a unregistered RS and have the AS produce a JWT access token with the resource as an audience if policy allows. That however was supposed to be dealt with as part of the mixed up client set of mitigations. In that the goal was to mitigate the attacks by returning meta-data about the tokens, and not to require discovery. We intend to return “iss” and “cleint_id” for the code, and I intend to discuss at the F2F returning resource for AT as well. Those mitigate the attack. I will continue to resist mixing up discovery of configuration meta-data with mitigation of the attacks. We return meta-data about the tokens now, because AT are opaque to the client, we neglected to include some of the information for the client needs to be secure. We just need to add that in to the existing flows. While Phil’s proposal is easier for the AS to implement as an add on, it puts more of a burden on the client needing to potentially change how it stores the relationships between AS and RS to prevent compromise, I think the solution should be biased towards simplicity on the client side. If we return the resources as part of the existing meta data the client checks that against the resource it intends to send the token to and if it is not in the list then it can’t send the token. Simple check every time it gets a new AT, no optionality. I am not saying anything new Nat has been advocating basically this for some time, and dis submit a draft. I prefer to return the info in the existing format rather than as link headers, but that is the largest difference between what Nat and I are saying with respect to resource. That is the core of my problem with Phil’s draft. I guess we will need to have a long conversation in BA. Regards John B. On Mar 13, 2016, at 8:12 PM, Phil Hunt <phil.h...@oracle.com<mailto:phil.h...@oracle.com>> wrote: This draft is a proposed alternate proposal for draft-ietf-oauth-discovery. As such, it contains the same registry for OAuth Config Metadata as the authors believe that both solutions are not required, or depending on WG discussion they will be merged. The intent is to provide a simple complete draft for consideration. How it works... Given that a client has previously discovered an OAuth protected resource, the bound configuration method allows a client to return the configuration for an oauth authorization server that can issue tokens for the resource URI specified by the client. The AS is not required to be in the same domain. The AS is however required to know if it can issue tokens for a resource service (which presumes some agreement exists on tokens etc). The draft does not require that the resource exist (e.g. for unconfigured or new user based resources). It only requires that the AS service provider agrees it can issue tokens. From a security perspective, returning the OAuth service configuration for a specified resource URI serves to confirm the client is in possession of a valid resource URI ensuring the client has received a valid set of endpoints for the resource and the associated oauth services. I propose that the WG consider the alternate draft carefully as well as other submissions and evaluate the broader discovery problem before proceeding with WGLC on OAuth Discovery. Thanks! Phil @independentid www.independentid.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.independentid.com%2f&data=01%7c01%7ctonynad%40microsoft.com%7c58284b200e8f43930bf708d34bc98ca0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=wYX1bvmaiwFUTnQfR4mcHcmzYtNA9K19vVwgPX%2fFki4%3d> phil.h...@oracle.com<mailto:phil.h...@oracle.com> Begin forwarded message: From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> Subject: New Version Notification for draft-hunt-oauth-bound-config-00.txt Date: March 13, 2016 at 3:53:37 PM PDT To: "Phil Hunt" <phil.h...@yahoo.com<mailto:phil.h...@yahoo.com>>, "Anthony Nadalin" <tony...@microsoft.com<mailto:tony...@microsoft.com>>, "Tony Nadalin" <tony...@microsoft.com<mailto:tony...@microsoft.com>> A new version of I-D, draft-hunt-oauth-bound-config-00.txt has been successfully submitted by Phil Hunt and posted to the IETF repository. Name: draft-hunt-oauth-bound-config Revision: 00 Title: OAuth 2.0 Bound Configuration Lookup Document date: 2016-03-13 Group: Individual Submission Pages: 22 URL: https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2finternet-drafts%2fdraft-hunt-oauth-bound-config-00.txt&data=01%7c01%7ctonynad%40microsoft.com%7c58284b200e8f43930bf708d34bc98ca0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=UB8l7iuCKiKlBGPc8FWwVGuX0sL30utwoGkHdnEP3dg%3d> Status: https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fdatatracker.ietf.org%2fdoc%2fdraft-hunt-oauth-bound-config%2f&data=01%7c01%7ctonynad%40microsoft.com%7c58284b200e8f43930bf708d34bc98ca0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=hRwZw4at5lMDnvxMQS998hoadtzmUuomSJnw5WcCNK8%3d> Htmlized: https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-hunt-oauth-bound-config-00&data=01%7c01%7ctonynad%40microsoft.com%7c58284b200e8f43930bf708d34bc98ca0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=fxrOEXrKOl%2beXwa%2fnM%2fEfHaRUXUIsHXcu3rfD3ofFQM%3d> Abstract: This specification defines a mechanism for the client of an OAuth 2.0 protected resource service to obtain the configuration details of an OAuth 2.0 authorization server that is capable of authorizing access to a specific resource service. The information includes the OAuth 2.0 component endpoint location URIs and as well as authorization server capabilities. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftools.ietf.org%2f&data=01%7c01%7ctonynad%40microsoft.com%7c58284b200e8f43930bf708d34bc98ca0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=4F7sO0JgzQvBe3HxUyOphLu85XG7U6hl3YTCrxkx8OY%3d>. The IETF Secretariat _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto: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%7c58284b200e8f43930bf708d34bc98ca0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=iJkkoG6Kd2NFkvAtwfZiyE4RBFNoSZhrPrxtmjZ9foE%3d>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
