Thanks George I think we have to discuss cases where mitigstion is not needed such as oidc.
My concern is to make the mitigation choice the AS's and not the client. Phil > On Mar 15, 2016, at 09:01, George Fletcher <gffle...@aol.com> wrote: > > I understand the benefit of having the client specify where it wants to > present the token. However, in general, the client knows which kind of > resource it's going to connect to (even if it doesn't know the exact > endpoint). For example, if the client speaks PortableContacts, then it can > potentially discover any PortableContact RS and attempt to get authorization > to access the endpoints, but the client can't connect to the mail RS because > it's not coded to work with those endpoints. > > Therefore, the client has an understanding of the protocol of the RS and can > possibly discover related endpoints (what webfinger was really designed for) > but it can't support some random new protocol. As I wrote in my response to > John Bradley, I believe audience binding should use an abstract identifier > not an API endpoint. > > Thanks, > George > >> On 3/15/16 11:40 AM, Phil Hunt wrote: >> Regarding 2. >> >> The bound config spec makes no such requirement of knowing the and its path >> structure. >> >> If you feel that you have other security measures and that clients will >> always have the proper AS, then you can wildcard the whole resource >> parameter. It still might be advisable to at least check that your clients >> are using a URL of the form https://*.aol.com/* or https://*.partner.com/*. >> >> The benefit is that at least you know the client is intending to wield the >> token somewhere in your domain or your partner’s domain. as opposed to >> something like news.aol.myevildomain.com. >> >> The difference here is that security remains the responsibility of the >> service provider in all cases. The check is up to the service provider >> rather than the client. This means that we don’t have to rely on trusting >> that the client developer bothered to check the configuration (as in other >> proposals that modify OAuth protocol itself) — we know well they won’t >> because they won’t have to. The server side validation is trivial. I’m not >> sure how much easier this can be. >> >> Phil >> >> @independentid >> www.independentid.com >> phil.h...@oracle.com >> >> >> >> >> >>> On Mar 15, 2016, at 8:09 AM, George Fletcher <gffle...@aol.com> wrote: >>> >>> I worry about two directions I see in this thread... >>> >>> 1. Client's accessing resources dynamically so that discovery is required >>> to know the correct AS, etc. This is pretty much the classic use case for >>> UMA and I'd rather not re-invent the wheel. >>> >>> 2. Creating a tight coupling between RS and AS such that RS endpoint >>> changes must be continually communicated to the AS. If an RS supports >>> multiple AS's then the RS has to deal with "guaranteed" delivery. The AS >>> needs an endpoint to receive such communications. If not dynamic via APIs, >>> then deployment of the new RS is bound by the associated AS's getting and >>> deploying the new endpoints. Can both endpoints of the RS be supported >>> within the AS for some period of time, etc. This is an operation nightmare >>> and almost assuredly going to go wrong in production. >>> >>> Maybe an OAuth2 "audience binding" spec is what's needed for those >>> deployments that require this. I believe that is what John Bradley is >>> suggesting. >>> >>> Thanks, >>> George >>> >>>> On 3/14/16 7:29 PM, Hans Zandbelt wrote: >>>> +1, I've found the very same in OAuth deployments that I was involved in; >>>> the hard part is to give names and descriptions to these concepts so that >>>> they cover all use cases and can be applied unambiguously >>>> >>>> Hans. >>>> >>>>> On 3/14/16 10:44 PM, Justin Richer wrote: >>>>> I agree that this is valuable, and not just for PoP. In all honesty, >>>>> it’s not even really required for PoP to function in many cases — it’s >>>>> just an optimization for one particular kind of key distribution >>>>> mechanism in that case. >>>>> >>>>> In the years of deployment experience with OAuth 2, I think we’ve really >>>>> got three different kinds of things that currently get folded into >>>>> “scope” that we might want to try separating out better: >>>>> >>>>> >>>>> - What things do I want to access? (photos, profile) >>>>> - What actions do I want to take on these things? (read, write, delete) >>>>> - How long do I want these tokens to work? >>>>> (offline_access/refresh_token, one time use, next hour, etc) >>>>> >>>>> >>>>> I think the first one is close to the audience/resource parameters that >>>>> have been bandied about a few times, including in the current token >>>>> exchange document. We should be consistent across drafts in that regard. >>>>> The second is more traditional scope-ish. The third has been patched in >>>>> with things like “offline_access” in certain APIs. >>>>> >>>>> Just another vector to think about if we’re going to be adding things >>>>> like “audience” or “resource” or both to the token requests. >>>>> >>>>> — Justin >>>>> >>>>> >>>>>> On Mar 14, 2016, at 6:26 PM, John Bradley <ve7...@ve7jtb.com >>>>>> <mailto:ve7...@ve7jtb.com>> wrote: >>>>>> >>>>>> Yes I will work on another proposal for allowing clients to specify >>>>>> what resource they want a token for and providing the meta-data to the >>>>>> client about the resources that a token is valid for. >>>>>> >>>>>> We have part of it in the POP key distribution spec and talked about >>>>>> separating it, as it is used more places than just for assigning keys. >>>>>> I know some AS use different token formats for different RS so are >>>>>> all-ready needing to pass the resource in the request to avoid making >>>>>> a mess of scopes. >>>>>> >>>>>> John B. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM) <phil.h...@oracle.com >>>>>>> <mailto:phil.h...@oracle.com>> wrote: >>>>>>> >>>>>>> Inline >>>>>>> >>>>>>> Phil >>>>>>> >>>>>>> On Mar 14, 2016, at 14:13, John Bradley <ve7...@ve7jtb.com >>>>>>> <mailto:ve7...@ve7jtb.com>> wrote: >>>>>>> >>>>>>>> We had two mandates. One was to provide a spec for AS metadata. >>>>>>>> The other was to mitigate the client mixup attack. The request was >>>>>>>> to do the latter without requiring the former for clients that don’t >>>>>>>> otherwise need discovery. >>>>>>> There is no mandate for any of this. See >>>>>>> http://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2016-01-22.txt >>>>>>> >>>>>>>> >>>>>>>> Returning the issuer and client_id from the authorization endpoint >>>>>>>> and the client checking them can be done by the client without >>>>>>>> discovery. >>>>>>> >>>>>>> How does this address the issue of whether the client is talking to >>>>>>> the wrong endpoint? >>>>>>>> >>>>>>>> Any client that has the resource and issuer hard coded probably >>>>>>>> doesn’t need discovery. >>>>>>> We agree >>>>>>> >>>>>>> >>>>>>>> One of the things that a client will need discovery for is to find >>>>>>>> the RS, so requiring the client to know the RS URI before getting >>>>>>>> the AS config seems backwards to me. >>>>>>> How can you make an assumption on order? You seem to be conflating >>>>>>> authentication with authorization by assuming the identity drives >>>>>>> what the resource is. >>>>>>> >>>>>>> There are lots of applications that require user rights but are not >>>>>>> identify centric. For example a document service. >>>>>>>> >>>>>>>> Unless the client tells the AS where it intends to use the token we >>>>>>>> will be leaving a security hole because the bearer tokens will have >>>>>>>> too loose an audience if they have one at all. >>>>>>> This is the biggest risk we have IMHO. >>>>>>>> >>>>>>>> True you are telling the AS (Webfinger service) what the RS is but >>>>>>>> that is not at a place that is useful in the token production process. >>>>>>> >>>>>>> This has nothing to do with token production. >>>>>>> >>>>>>> What we want to ensure is whether an honest client is correctly >>>>>>> configured and has not been mislead - eg by a phishing page. >>>>>>>> >>>>>>>> I also think there are use cases where the AS doesn’t know all the >>>>>>>> possible RS. That is not something that a out of band check can >>>>>>>> address. >>>>>>> >>>>>>> May be. Lets identify them. >>>>>>> >>>>>>>> There are also cases where a token might be good at multiple RS >>>>>>>> endpoints intentionally. >>>>>>> >>>>>>>> In your solution the client would need to make a discovery request >>>>>>>> for each endpoint. >>>>>>> Sure. Otherwise how would it know if there is one AS or a pool of AS >>>>>>> servers assigned to each instance? >>>>>>>> Those requests lack the context of who the client and resource owner >>>>>>>> are. I think that will be a problem in some >>>>>>>> use cases. >>>>>>> >>>>>>> Not sure I agree. This is about discovering a valid set of endpoints. >>>>>>> For mitm, we mainly want to check the hostname is correct. If a >>>>>>> client chooses evil.com <http://evil.com/> the >>>>>>> cert can be valid and >>>>>>> TLS will pass. How does it otherwise know it is supposed to talk to >>>>>>> res.example.com <http://res.example.com/>? >>>>>>>> >>>>>>>> If this is added to the token endpoint it would be checked when code >>>>>>>> or refresh are exchanged, not every time the token is used. >>>>>>> Your proposal requires rhe client to check. I am not clear how the AS >>>>>>> can know the exact uri. It is far easier to validate than to lookup >>>>>>> since as you say the client may be authorized to use multiple ASs. >>>>>>>> With a out of band check the client would never know if a RS was >>>>>>>> removed/revoked. >>>>>>> >>>>>>> Not sure that is in scope. >>>>>>> >>>>>>> None of the current proposals address this issue. >>>>>>>> >>>>>>>> I don’t see checking when refreshing a token as something that is a >>>>>>>> huge burden. >>>>>>> >>>>>>> Still its a lot more than once. >>>>>>> >>>>>>> Why don't you draft another alternative? >>>>>>>> >>>>>>>> If the server wants to do the check on it’s side then we could >>>>>>>> require the client to send the RS URI in the token request. that way >>>>>>>> you really know the client is not going to get a token for the wrong >>>>>>>> RS endpoint. >>>>>>>> If you check out of band in discovery you really have no idea if the >>>>>>>> client is checking. >>>>>>> >>>>>>> In the new webfinger draft, the client isn't checking. The service >>>>>>> provider simply does not disclose oauth information to misconfigured >>>>>>> clients. >>>>>>>> >>>>>>>> John B. >>>>>>>> >>>>>>>> >>>>>>>>> On Mar 14, 2016, at 3:56 PM, Phil Hunt <phil.h...@oracle.com >>>>>>>>> <mailto:phil.h...@oracle.com>> wrote: >>>>>>>>> >>>>>>>>> Thanks to Mike and John for their feedback. I’ll take each in turn: >>>>>>>>> >>>>>>>>> Mike, >>>>>>>>> >>>>>>>>> Regarding your suggested amendments >>>>>>>>> >>>>>>>>> Item 1: Returning the config URL would create two problems. One,it >>>>>>>>> makes bound discovery a two-step process - that adds complexity. >>>>>>>>> It seems far simpler to mandate TLS (which I think it already does >>>>>>>>> in the security considerations). >>>>>>>>> >>>>>>>>> The two-step process allows the current discovery process to >>>>>>>>> continue. I disagree with this. This is why >>>>>>>>> I put forward an >>>>>>>>> “alternate" draft that is almost the same but simply adds the check >>>>>>>>> before returning the configuration data. I >>>>>>>>> worry that developers >>>>>>>>> would have no incentive to do the two-step approach. They would >>>>>>>>> just start at step 2 which in turn puts AS’s at risk of exposing >>>>>>>>> tokens because it works. This makes OAuth promiscuous. >>>>>>>>> >>>>>>>>> Regarding existing implementations. Most of those implementations >>>>>>>>> are for OIDC. I think it makes sense for OIDF to continue use of >>>>>>>>> OIDC's discovery spec because the UserInfo endpoint is well defined >>>>>>>>> and the likelihood of a client mis-informed about the resource >>>>>>>>> endpoint is not there. IMO This does not >>>>>>>>> apply to the broader >>>>>>>>> OAuth community. >>>>>>>>> >>>>>>>>> Item 2: It may be appropriate to have a separate configuration >>>>>>>>> registry specification, but I think we should hold off until we >>>>>>>>> have a complete solution and then make the decision what drafts >>>>>>>>> should exist and how many pieces. A big concern is the perceived >>>>>>>>> complexity of multiple solutions and multiple drafts. >>>>>>>>> >>>>>>>>> As to John Bradley’s comments: >>>>>>>>> >>>>>>>>> Re: Discovery is the wrong place to mitigate threats. >>>>>>>>> I’m confused by this. Our mandate was to solve a security threat >>>>>>>>> by having a discovery specification to prevent clients being >>>>>>>>> mis-lead about endpoints (of which resource service is one) in an >>>>>>>>> oauth protected exchange. Maybe what you mean is we should not use >>>>>>>>> .well-known of any kind and we should just create a “/Config” >>>>>>>>> endpoint to OAuth? >>>>>>>>> >>>>>>>>> Re: Your proposal for MITM mitigation >>>>>>>>> You propose that instead the resource endpoint check should be in >>>>>>>>> the oauth protocol itself. The difference is that validation is >>>>>>>>> transferred back to the client to get it right. As well, without >>>>>>>>> the client informing the AS, I can’t see a way for the AS to know >>>>>>>>> what endpoint the client is using. The webfinger approach does >>>>>>>>> this once and only requires that the host name be checked in many >>>>>>>>> cases. >>>>>>>>> >>>>>>>>> As a principle, the members have discussed many times that the AS >>>>>>>>> service should do validation when possible — this was particularly >>>>>>>>> true at the Germany meeting when this came up. This is why I prefer >>>>>>>>> the client tell the service provider what it intends to do and the >>>>>>>>> service provider can fail that request immediately if necessary. We >>>>>>>>> don’t have to depend on the developer getting the spec correct to >>>>>>>>> fail the correct way. >>>>>>>>> >>>>>>>>> I worry that adding more parameters to the authz and token protocol >>>>>>>>> flows increases complexity and attack surface. It also means per >>>>>>>>> authorization validation has to take place >>>>>>>>> vs. a one-time >>>>>>>>> validation at config time. Placing it in the configuration lookup >>>>>>>>> phase (whether via web finger or just a special OAuth endpoint) >>>>>>>>> seems more appropriate and far less complex - as the request itself >>>>>>>>> is simple and has only one parameter. Here we are not considered >>>>>>>>> about legitimacy of the client. we’re just concerned with the issue >>>>>>>>> "has the client been correctly informed?” >>>>>>>>> >>>>>>>>> That said, it may be that when we consider all the use cases, some >>>>>>>>> combination of AS protocol and discovery may be both needed. I’m >>>>>>>>> not ready to make conclusions about this. The current >>>>>>>>> oauth-discovery spec seems to put future generic clients at risk >>>>>>>>> and that is my primary concern. >>>>>>>>> >>>>>>>>> Best Regards, >>>>>>>>> >>>>>>>>> Phil >>>>>>>>> >>>>>>>>> @independentid >>>>>>>>> www.independentid.com <http://www.independentid.com/> >>>>>>>>> phil.h...@oracle.com <mailto:phil.h...@oracle.com> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Mar 13, 2016, at 10:28 PM, Mike Jones >>>>>>>>>> <michael.jo...@microsoft.com <mailto:michael.jo...@microsoft.com>> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> 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 >>>>>>>>>> athttp://openid.net/certification/(see the “OP Config” column in >>>>>>>>>> the table) andOAuth 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 <http://www.independentid.com/> >>>>>>>>>> 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 >>>>>>>>>> Status: >>>>>>>>>> >>>>>>>>>> https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/ >>>>>>>>>> Htmlized: >>>>>>>>>> https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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 >>>>>>>>>> attools.ietf.org <http://tools.ietf.org/>. >>>>>>>>>> >>>>>>>>>> The IETF Secretariat >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org <mailto: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 > > -- > Chief Architect > Identity Services Engineering Work: george.fletc...@teamaol.com > AOL Inc. AIM: gffletch > Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch > Office: +1-703-265-2544 Photos: http://georgefletcher.photography
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
