Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-10.txt

[John Bradley <[e-mail]>]

Consider if you will a world where IdP support multiple LoA.

This allows a RP to register the method required for there use case.

If a Client requires the asymmetrically signed JWT assertions rather than http basic,  it doesn't want the Authorization server accepting http_basic for it's client_id.

The reason a client/RP would want to specify multiple LoA is the same reason they may wan to in SAML or other protocols.

The issue is more that different clients will have different security requirements and this allows them to dynamic register those.

If you allow 2 and 3 the one that need 3 will specify that.

John

On 2013-05-09, at 3:32 PM, Phil Hunt <[e-mail]> wrote:

> Giving the client the choice lets the client choose lower LoA and downgrade.  Surely it is the server that is taking the risk so the server has the right to set the requirements.
> 
> Why would a server tolerate multiple levels of LoA from the same client application?  Why is that needed?
> 
> If a server allows 2 and 3, then all clients will choose 2 -- or at the very least your overall security drops to 2.  This is not good.
> 
> Phil
> 
> @independentid
> www.independentid.com
> [e-mail]
> 
> 
> 
> 
> 
> On 2013-05-09, at 3:17 PM, John Bradley wrote:
> 
>> The client needs to be able to say only use a particular auth method to disallow the Authorization server from providing a weaker method to an attacker.  
>> 
>> This is a required parameter to allow a Authorization server to support high and low LoA clients dynamically.
>> 
>> John B.
>> 
>> 
>> On 2013-05-09, at 2:44 PM, Phil Hunt <[e-mail]> wrote:
>> 
>>> Justin,
>>> 
>>> Just to progress towards resolving this issue, what I would like to understand is how specifying authentication type makes things simpler or more inter-operable. I'm concerned that the logic you proposed early in the thread is a lot more complexity.  I would prefer just having the server tell the client what authentication it MUST use.
>>> 
>>> As an alternative, the negotiation for credential method/type could occur during the initial developer registration of the app.  As in your "blue button" health case (did I remember that right), the initial registration JWT would be used in the dynamic registration and allow the registration server to observe any previously negotiated client preferences OOB of this spec.  Or, are you saying that individual instances have some need to change authentication types on a per deployment basis independent of what the associated authorization server wants them to use? If so what is it?
>>> 
>>> Phil
>>> 
>>> @independentid
>>> www.independentid.com
>>> [e-mail]
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On 2013-05-06, at 11:56 AM, Phil Hunt wrote:
>>> 
>>>> Justin,
>>>> 
>>>> What you describe, though good intentioned, seems like a lot of complexity without getting an actual benefit. I would rather not have token_endpoint_auth_method at all.
>>>> 
>>>> Think about someone writing a general purpose SCIM client or OIDC client.  Site as uses method 1 and 2, site b supports 2,3 and 4.  Site c only 5 and 6.  So if each site is willing to negotiate authn, how has this developer's coding been reduced? The developer will end up having to implement all popular methods regardless of discovery or the ability of the client to select. In fact, they have to do all the logic you describe below AND implement all methods.
>>>> 
>>>> I have also thought through, does it matter since it is optional?  I think it does. If servers just ignore the param most of the time, what value is there?
>>>> 
>>>> Phil
>>>> 
>>>> @independentid
>>>> www.independentid.com
>>>> [e-mail]
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On 2013-05-06, at 8:39 AM, Richer, Justin P. wrote:
>>>> 
>>>>> In spite of what John seems to think, that dependency was never there. The whole discovery process is related, but separate, from registration. It could happen using OIDC, it could happen with Bill Mills's LRDD link types, it could happen with Nat's proposed HAL-based system, it could happen by the developer going to the service provider's documentation page and reading a bunch of text (which is what happens with large OAuth providers today) -- it ultimately doesn't matter. 
>>>>> 
>>>>> And I think that the Dynamic Registration protocol that we have here is robust against that kind of diversity. Let's take the token_endpoint_auth_method parameter as an example. Let's say a client shows up to a service it's just discovered -- through whatever means, we don't actually care. This client either has some idea of what auth methods the server supports (through a discovery mechanism) or it doesn't. If it does, it will also know which methods it supports and it can pick one. If it doesn't, it will still know which methods it supports and will just pick one. The server will then take that information and do one of three things:
>>>>> 
>>>>> 1) Accept what the client proposes and use that. This is of course the ideal situation where everybody gets what they want, and this can be brought about more often by a good discovery process.
>>>>> 2) Reject what the client proposes with an error code (invalid_client_metadata would cover this). The client then has to re-register with a different value or just give up because the two systems are using different auth methods that can't be reconciled.
>>>>> 3) Ignore what the client proposes and return the server's preferred method. The client can then, in turn:
>>>>> a) Accept what the server returns and use that, if it supports it. This is also ideal because everybody is happy again.
>>>>> b) Reject what the server returns and either try the registration again with another value or give up.
>>>>> c) Ignore what the server returns and fail when doing a token request. This would be a dumb thing for a dumb client to do. 
>>>>> 
>>>>> Alternatively, the client could just not mention it and have the server dictate what method it will use, and the client will either accept, reject, or ignore it. This process applies to every parameter in the system, from something innocuous as the client's TOS uri to something as security-critical as the redirect_uri (which gets its own special error message). 
>>>>> 
>>>>> I think that the assumption of full automation for all clients to all servers is a red herring in the OAuth world for the simple fact that the API that's being accessed/protected isn't going to be universally compatible anyway. I agree fully that a well-specified service discovery is important and we should, as a working group, help figure out what that looks like. As mentioned above, several of us already are. But I don't think it's helpful to conflate the registration and discovery processes and turn them into some kind of negotiation system. I think we can do a good job of making it widely useful without that.
>>>>> 
>>>>> -- Justin
>>>>> 
>>>>> On May 5, 2013, at 1:05 PM, Phil Hunt <[e-mail]>
>>>>> wrote:
>>>>> 
>>>>>> Justin,
>>>>>> 
>>>>>> Has the assumption of a discovery service defined by OIDC been removed?
>>>>>> 
>>>>>> Phil
>>>>>> 
>>>>>> @independentid
>>>>>> www.independentid.com
>>>>>> [e-mail]
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 2013-05-05, at 12:52 PM, Richer, Justin P. wrote:
>>>>>> 
>>>>>>> Handful of minor changes in this revision, including tightening the language around scopes and adding an absolute-URI based mechanism for extending token_endpoint_auth_method (no registry, still). No normative changes beyond removing an unreachable error state. (Thanks, Nov.) Please check the diffs, we welcome feedback. I personally think this is really getting close to final.
>>>>>>> 
>>>>>>> -- Justin
>>>>>>> 
>>>>>>> On May 5, 2013, at 3:45 PM, <[e-mail]>
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> 
>>>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>>>>>> This draft is a work item of the Web Authorization Protocol Working Group of the IETF.
>>>>>>>> 
>>>>>>>> 	Title           : OAuth 2.0 Dynamic Client Registration Protocol
>>>>>>>> 	Author(s)       : Justin Richer
>>>>>>>>                   John Bradley
>>>>>>>>                   Michael B. Jones
>>>>>>>>                   Maciej Machulak
>>>>>>>> 	Filename        : draft-ietf-oauth-dyn-reg-10.txt
>>>>>>>> 	Pages           : 25
>>>>>>>> 	Date            : 2013-05-05
>>>>>>>> 
>>>>>>>> Abstract:
>>>>>>>> This specification defines an endpoint and protocol for dynamic
>>>>>>>> registration of OAuth 2.0 Clients at an Authorization Server and
>>>>>>>> methods for the dynamically registered client to manage its
>>>>>>>> registration.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> The IETF datatracker status page for this draft is:
>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg
>>>>>>>> 
>>>>>>>> There's also a htmlized version available at:
>>>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-10
>>>>>>>> 
>>>>>>>> A diff from the previous version is available at:
>>>>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-10
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> OAuth mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>> 
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>