On 3/15/16 6:14 PM, John Bradley wrote:
> If the AS is audience restricting the tokens then it just needs to put
> the right audience in the token based on what the client is asking for.
> That is safe as the RS wouldnât be able to replay the token someplace
> else.
So let's assuming a client sends a token audience restricted to GoodRS
instead to EvilRS. When EvilRS replays the token at the GoodRS endpoint,
how does GoodRS reject the token because when GoodRS sends the token to
the AS for introspection (or does so itself) the token will be audience
restricted to the GoodRS and it will process the token. The only way to
prevent this is with client-authentication so that the presenter can be
matched against who is allowed to present the token (aka PoP).
In the pure bearer token model, I don't see how this can be prevented at
the protocol level.
>
> That would need to be a AS policy if it wanted to do that for unknown RS.
>
> Allowing more than one audience in a token is a convince but a well
> known security risk with bearer tokens.
True, but this means clients have to manage many tokens or call the
token endpoint to get a "downscoped, audience restricted" token every
time they need one. This is a very different model than what most people
think of when they think of OAuth2. Not bad, just different:)
>
> A AS would probably want to have only one audience in a AT for a
> untrusted RS, but may allow multiple if they are all trusted.
>
> John B.
>
>
>> On Mar 15, 2016, at 6:28 PM, George Fletcher <***@aol.com
>> <mailto:***@aol.com>> wrote:
>>
>>
>> On 3/15/16 3:26 PM, John Bradley wrote:
>>> I think Phil and others are concerned that a developer might get bad
>>> info to put in the client , some out of band discovery goes wrong or
>>> the user is somehow tricked into specifying a bad resource to the
>>> client.
>>>
>>> So getting a bad resource is a touch hypothetical.
>> If we are really trying to solve this problem holistically, then we
>> probably need to first describe the use cases we want to solve. I'm
>> starting to wonder if we are all providing solutions to slightly
>> different use cases.
>>>
>>> For Connect we could suppose that someone publishes a malicious
>>> discovery document listing themselves as the RS but all the other
>>> endpoints are at the good AS so the client registers, authorizes the
>>> user and gives the AT to the bad guy. The confused client
>>> mitigation by returning client_id_and issuer from the authorization
>>> endpoint will stop the attack before the token can be given to the
>>> token endpoint or RS.
>> Agreed and I'm fine with this solution.
>>>
>>> So protecting the AT at this point is more for a unknown attack that
>>> would confuse whatever protocol/API that is using OAuth about what
>>> RS to use.
>> Yes. This is where we need to describe some use cases (preferably
>> real vs contrived) before we propose solutions. In most cases the RS
>> endpoints are hard coded into the client or maybe pulled from a
>> different central config endpoint (which is fixed).
>>
>> That's why the only case I could think of is a client that works with
>> multiple RS endpoints from different providers that server the same
>> content (e.g. PortableContacts API). In this use case, the user of
>> the client would need to enter the location of the RS they wanted to
>> use and then the flow would start from there. In reality, most
>> services like this would have a fixed set of RS's they work with and
>> again it wouldn't be dynamic.
>>>
>>> In reality this is what PoP is supposed to be for.
>>>
>>> I guess the question is what short of PoP can we do to prevent the
>>> client leaking tokens to bad RS that confuse it via the application
>>> protocol.
>>>
>>> If we want to del with this in OAuth then we need to tell the AS
>>> where the token is going to be used or tel the client where the
>>> token can be used.
>>>
>>> I think letting the client tell the AS where it wants the token used
>>> having the AS construct a audience out of that is probably the best
>>> thing. to get around having a pre-established relationship between
>>> the AS and RS.
>> Even if the client tells the AS where it wants to use the token (via
>> some endpoint URL), the AS still needs to have a relationship with
>> the RS (at a minimum as an endpointURL-to-RS map) otherwise how can
>> it determine if it is allowed to issue an access token to the user
>> for that RS. This map is what I want to avoid "building" into the AS.
>> Do we need "dynamic RS registration" to support this?
>>
>>>
>>> John B.
>>>
>>>> On Mar 15, 2016, at 3:14 PM, George Fletcher <***@aol.com
>>>> <mailto:***@aol.com>> wrote:
>>>>
>>>>
>>>>
>>>> I think Justin provided a good break down of the different aspects
>>>> a client wants to specify about the requested token. (my paraphrase)
>>>> 1. what RS's the token will be used at
>>>> 2. authorization privilege requests
>>>> 3. token-timing adjustments
>>>>
>>>> I'm not sure passing the full endpoint to the AS will help with my
>>>> concerns... The AS could potentially do a webfinger on the resource
>>>> URI and determine if it's an RS that it supports... though that
>>>> requires all RS's to support webfinger. What I really want to avoid
>>>> is the AS having this list of URIs to RS that is almost assuredly
>>>> to get out of sync.
>>>>
>>>>
>>>>
>>>> On 3/15/16 1:56 PM, John Bradley wrote:
>>>>> I think it is a AS policy decision if it should error or take the
>>>>> requested resource and issue a token audianced for that resource.
>>>> Actually, the error cases are interesting. What if the passed in
>>>> resource/audience doesn't actually match a requested scope? Or some
>>>> match and some don't? Is it better to send back a token with less
>>>> capability? or error the entire request?
>>>>>
>>>>> I guess the question is how to transition from now to a future
>>>>> state. If you cannot upgrade all the clients at once.
>>>>>
>>>>> A processing rule on the AS that allowed some clients to not send
>>>>> the requested resource , but would error out for other upgraded
>>>>> clients with a "resource not allowedâ oauth error would work and
>>>>> not require the return of the resources.
>>>>>
>>>>> If you return the resources and let the client error if it is
>>>>> trying to send to the wrong endpoint that make upgrading easier,
>>>>> but gives less control to the AS.
>>>>>
>>>>> I could live with it ether way.
>>>>>
>>>>> The advantage of always sending it in the token request is that it
>>>>> allows the AS to do the mapping from a resource URI to one or more
>>>>> abstract audience for the token.
>>>> I thought Justin provided a good break down of the different
>>>> aspects a client wants to specify about the requested token. (my
>>>> paraphrase)
>>>> 1. what RS's the token will be used at
>>>> 2. authorization privilege requests
>>>> 3. token-timing adjustments
>>>>
>>>> The question is how does a client internally reference a resource
>>>> server? If it's a fixed RS endpoint, then it sort of doesn't
>>>> matter, the client isn't going to send the token to the wrong
>>>> endpoint anyway and it can easily reference the audience by an
>>>> abstract URI.
>>>>
>>>> If the client can dynamically find new RS's to interact with. How
>>>> does that happen? Does the client get handed an endpoint to use? or
>>>> does it do some sort of discovery to determine the endpoint? I
>>>> suppose both are possible.
>>>>
>>>> Could we prescribe that the realm value of RFC 6750 error response
>>>> be effectively a resource-service-id (like issuer for the AS). The
>>>> client would then need to do discovery on that value to find the
>>>> valid endpoints of the RS. This could be done once and the
>>>> resource-service-id could be used as the "abstract" RS identifier.
>>>> This requires no more discovery than adding an AS to the client.
>>>>>
>>>>> That might help address Georgeâs concern.
>>>> I'm not sure passing the full endpoint to the AS will help with my
>>>> concerns... The AS could potentially do a webfinger on the resource
>>>> URI and determine if it's an RS that it supports... though that
>>>> requires all RS's to support webfinger. What I really want to avoid
>>>> is the AS having this map of URIs to RS that is almost assuredly to
>>>> get out of sync.
>>>>>
>>>>> John B.
>>>>>
>>>>>
>>>>>> On Mar 15, 2016, at 2:44 PM, Brian Campbell
>>>>>> <***@pingidentity.com <mailto:***@pingidentity.com>>
>>>>>> wrote:
>>>>>>
>>>>>> I was thinking it'd be simpler to error, if the requested
>>>>>> resource(s) weren't okay. That puts the burden of checking in the
>>>>>> AS. And doesn't add anything to the token or authorization
>>>>>> response. I see the potential similarity to scope but not sure
>>>>>> it's worth it.
>>>>>>
>>>>>> On Tue, Mar 15, 2016 at 11:37 AM, John
>>>>>> Bradley<***@ve7jtb.com>wrote:
>>>>>>
>>>>>> If the client specifies the resource it wants the token for,
>>>>>> then the meta-data would not be required unless the resources
>>>>>> the token is good at are different from the request.
>>>>>> Lat is the same logic as scopes.
>>>>>>
>>>>>> For backwards compatibility if the client is happy with the
>>>>>> default resources based on scopes then I think it is a good
>>>>>> idea to tell the client what the resources are in the response.
>>>>>>
>>>>>> I suspect that it is simpler with less optionality and always
>>>>>> return the resources, even if they are not required.
>>>>>>
>>>>>> John B.
>>>>>>
>>>>>>> On Mar 15, 2016, at 12:46 PM, Brian Campbell
>>>>>>> <***@pingidentity.com> wrote:
>>>>>>>
>>>>>>> If the client specifies the desired audience(s)/resource(s),
>>>>>>> is that metadata to the client needed? The AS can audience
>>>>>>> restrict the token as needed or respond with an error if it
>>>>>>> can't or wont issue a token for the resource the client
>>>>>>> asked for.
>>>>>>>
>>>>>>> On Tue, Mar 15, 2016 at 9:37 AM, John
>>>>>>> Bradley<***@ve7jtb.com>wrote:
>>>>>>>
>>>>>>> Yes, I think bearer tokens with no audience are a bad
>>>>>>> idea.
>>>>>>>
>>>>>>> The AS needs to infer an audience from the scopes snd/or
>>>>>>> have the client specify the desired audience.
>>>>>>>
>>>>>>> If the AT has a audience or audiences then as long as
>>>>>>> the endpoint URI are provided as meta-data with the
>>>>>>> token, the client can determine if it is sending the
>>>>>>> token to the correct place.
>>>>>>>
>>>>>>> I think Phil would prefer the server rather than the
>>>>>>> client do the check, but the client always needs to take
>>>>>>> some responsibility to not leak tokens giving them to
>>>>>>> the wrong RS or the code to the wrong token endpoint is
>>>>>>> leaking.
>>>>>>>
>>>>>>> I imagine that claims based access tokens are going to
>>>>>>> become more popular and the static relationship between
>>>>>>> one RS and one AS will not be the majority of
>>>>>>> deployments over time.
>>>>>>>
>>>>>>> In any case where the client is configured up front to
>>>>>>> know the RS and the AS it seems like that would not
>>>>>>> require Philâs Solution, but that is the only case
>>>>>>> supported by that discovery.
>>>>>>> If the client itself is bad there is not much you can do
>>>>>>> to stop it from passing on the AT in way way it wants.
>>>>>>> That however is a different problem and needs claimed
>>>>>>> URI or attestations to prevent client spoofing.
>>>>>>> William and I are working on that in the mobile best
>>>>>>> practices draft.
>>>>>>>
>>>>>>> John B.
>>>>>>>
>>>>>>>
>>>>>>>> On Mar 15, 2016, at 12:09 PM, George Fletcher
>>>>>>>> <***@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
>>>>>>>>>>> <***@ve7jtb.com
>>>>>>>>>>> <mailto:***@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)
>>>>>>>>>>>> <***@oracle.com
>>>>>>>>>>>> <mailto:***@oracle.com>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Inline
>>>>>>>>>>>>
>>>>>>>>>>>> Phil
>>>>>>>>>>>>
>>>>>>>>>>>> On Mar 14, 2016, at 14:13, John Bradley
>>>>>>>>>>>> <***@ve7jtb.com
>>>>>>>>>>>> <mailto:***@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 choosesevil.com
>>>>>>>>>>>> <http://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/><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
>>>>>>>>>>>>>> <***@oracle.com
>>>>>>>>>>>>>> <mailto:***@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/>
>>>>>>>>>>>>>> ***@oracle.com<mailto:***@oracle.com>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Mar 13, 2016, at 10:28 PM, Mike Jones
>>>>>>>>>>>>>>> <***@microsoft.com<mailto:***@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-***@ietf.org]*On
>>>>>>>>>>>>>>> Behalf Of*John Bradley
>>>>>>>>>>>>>>> *Sent:*Sunday, March 13, 2016 6:45 PM
>>>>>>>>>>>>>>> *To:*Phil Hunt
>>>>>>>>>>>>>>> <***@oracle.com<mailto:***@oracle.com>>
>>>>>>>>>>>>>>> *Cc:*oauth <***@ietf.org<mailto:***@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
>>>>>>>>>>>>>>> <***@oracle.com
>>>>>>>>>>>>>>> <mailto:***@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/>
>>>>>>>>>>>>>>> ***@oracle.com<mailto:***@oracle.com>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Begin forwarded message:
>>>>>>>>>>>>>>> *From:*internet-***@ietf.org
>>>>>>>>>>>>>>> <mailto:internet-***@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" <***@yahoo.com
>>>>>>>>>>>>>>> <mailto:***@yahoo.com>>, "Anthony Nadalin"
>>>>>>>>>>>>>>> <***@microsoft.com<mailto:***@microsoft.com>>,
>>>>>>>>>>>>>>> "Tony Nadalin" <***@microsoft.com
>>>>>>>>>>>>>>> <mailto:***@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://attools.ietf.org/><http://tools.ietf.org/>.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The IETF Secretariat
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>>>>>> ***@ietf.org<mailto:***@ietf.org>
>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>> ***@ietf.org<mailto:***@ietf.org>
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> OAuth mailing list
>>>>>>>>>> ***@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> ***@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>
>
--
Chief Architect
Identity Services Engineering Work: ***@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