Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Phil Hunt <phil.hunt@oracle.com>
In-Reply-To: <86F7EC4C-DDF3-42B7-8355-A8C684CC2D2F@ve7jtb.com>
Date: Thu, 9 May 2013 15:32:25 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <3B38531B-AED4-459C-9B9F-A57DE04AB467@oracle.com>
References: <20130505194505.24986.11173.idtracker@ietfa.amsl.com>
 <6214B696-54F2-4D26-BB0B-AD045F6A96BB@mitre.org>
 <C7E72257-1A96-4D14-ABEA-3940E346935C@oracle.com>
 <6A775D1B-47DE-48BD-849B-D964BAE5B4E9@mitre.org>
 <9B5D63B5-A923-415C-8593-7EC228256992@oracle.com>
 <E66BAB7C-C088-418A-B3F9-92525F336852@oracle.com>
 <86F7EC4C-DDF3-42B7-8355-A8C684CC2D2F@ve7jtb.com>
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: "oauth@ietf.org WG" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-10.txt
Precedence: list

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
phil.hunt@oracle.com





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. =20
>=20
> This is a required parameter to allow a Authorization server to =
support high and low LoA clients dynamically.
>=20
> John B.
>=20
>=20
> On 2013-05-09, at 2:44 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
>=20
>> Justin,
>>=20
>> 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.
>>=20
>> 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?
>>=20
>> Phil
>>=20
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>>=20
>>=20
>>=20
>>=20
>>=20
>> On 2013-05-06, at 11:56 AM, Phil Hunt wrote:
>>=20
>>> Justin,
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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?
>>>=20
>>> Phil
>>>=20
>>> @independentid
>>> www.independentid.com
>>> phil.hunt@oracle.com
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> On 2013-05-06, at 8:39 AM, Richer, Justin P. wrote:
>>>=20
>>>> 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.=20
>>>>=20
>>>> 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:
>>>>=20
>>>> 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.=20
>>>>=20
>>>> 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).=20
>>>>=20
>>>> 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.
>>>>=20
>>>> -- Justin
>>>>=20
>>>> On May 5, 2013, at 1:05 PM, Phil Hunt <phil.hunt@oracle.com>
>>>> wrote:
>>>>=20
>>>>> Justin,
>>>>>=20
>>>>> Has the assumption of a discovery service defined by OIDC been =
removed?
>>>>>=20
>>>>> Phil
>>>>>=20
>>>>> @independentid
>>>>> www.independentid.com
>>>>> phil.hunt@oracle.com
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On 2013-05-05, at 12:52 PM, Richer, Justin P. wrote:
>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> -- Justin
>>>>>>=20
>>>>>> On May 5, 2013, at 3:45 PM, <internet-drafts@ietf.org>
>>>>>> wrote:
>>>>>>=20
>>>>>>>=20
>>>>>>> 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.
>>>>>>>=20
>>>>>>> 	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
>>>>>>>=20
>>>>>>> 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.
>>>>>>>=20
>>>>>>>=20
>>>>>>> The IETF datatracker status page for this draft is:
>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg
>>>>>>>=20
>>>>>>> There's also a htmlized version available at:
>>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-10
>>>>>>>=20
>>>>>>> A diff from the previous version is available at:
>>>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-10
>>>>>>>=20
>>>>>>>=20
>>>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>=20
>>>>=20
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20