Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Thu 22 Aug, 2pm PDT

[Torsten Lodderstedt <[e-mail]>]

Hi Phil,

I agree, the client may also present a client_id obtained from another "source". But: the AS must be able to associate a policy with this particular id. This typically requires a provisioning of the client id before the actual OAuth interaction takes place. Otherwise the AS does not have any information regarding the client id in the code flow at authz endpoint.

This needs to be taken into account.

regards,
Torsten.

Am 20.08.2013 um 08:12 schrieb Phil Hunt <[e-mail]>:

> Sorry i see my message still isn't that clear.  I am saying there is no requirement that a client directly obtain a client_id from the as service provider. It is merely an assumption that has been made by dyn reg based on typical use patterns to date. 
> 
> It could be reasonable for a client to generate it's own guid or more likely, use an assertion signed by a party the service provider trusts. 
> 
> Phil
> 
> On 2013-08-19, at 22:53, Phil Hunt <[e-mail]> wrote:
> 
>> See below
>> 
>> Phil
>> 
>> On 2013-08-19, at 22:34, Torsten Lodderstedt <[e-mail]> wrote:
>> 
>>> Hi Phil,
>>> 
>>> 
>>> 
>>> 
>>>> The assumption that client id must be issued by the sp seems wrong to
>>>> me in many cases-- including oidc. 6749 does not make this restriction
>>>> at all.
>>> 
>>> What do you mean? Grant type code requires a client_id in order to identify the client at the AS's authz endpoint. Based on this data, the AS chooses the authz policy and validates the redirect_uri.
>> 
>> [ph] yes. But i am referring to the fact that the client does not have to obtain it from the as. It merely has to present one that is accepted. 
>> 
>> Iow a federated assertion might solve the issue. 
>>> 
>>>> 
>>>> Given this, a statement approach may be sufficient for many clients. No
>>>> need for long term credential mgmt or records.
>>> 
>>> Perhaps for clients using the token endpoint only.
>> 
>> [Ph] Actually I was also thinking of javascript clients. 
>>> 
>>> regards,
>>> Torsten.
>>> 
>>>> 
>>>> Phil
>>>> 
>>>> On 2013-08-19, at 16:33, Eve Maler <[e-mail]> wrote:
>>>> 
>>>>> Hi folks-- Just a reminder that the first draft the UMA group
>>>> submitted on May 1, 2011 contained extensive requirements and use cases
>>>> related to UMA's various needs for dynamic client registration:
>>>>> 
>>>>> http://tools.ietf.org/html/draft-hardjono-oauth-dynreg-00
>>>>> 
>>>>> When there was interest to pick up this draft as a WG work item, it
>>>> was recommended that we excise this content so that the doc wouldn't be
>>>> so specific to our particular usage of OAuth.
>>>>> 
>>>>> I point this out just to show that the need for dynamic client
>>>> registration isn't limited to OpenID Connect, and that some specific
>>>> use cases have already been floated here.
>>>>> 
>>>>> FWIW,
>>>>> 
>>>>> Eve
>>>>> 
>>>>> On 19 Aug 2013, at 8:31 AM, Justin Richer <[e-mail]> wrote:
>>>>> 
>>>>>> All of this is a good argument to do both, which is what I've been
>>>> saying all along.
>>>>>> 
>>>>>> -- Justin
>>>>>> 
>>>>>> On 08/19/2013 11:33 AM, Phil Hunt wrote:
>>>>>>> I do not recall agreement in charter discussions to solving a
>>>> specific case.
>>>>>>> 
>>>>>>> I recall more than one in the re-chartering discussion said dyn reg
>>>> needed major changes to solve their use cases.
>>>>>>> 
>>>>>>> Phil
>>>>>>> 
>>>>>>> On 2013-08-19, at 8:18, Justin Richer <[e-mail]> wrote:
>>>>>>> 
>>>>>>>> Tony, I completely disagree. The proposals that I've seen have
>>>> different means and different end states, and they make different
>>>> assumptions about the relationship between entities and the
>>>> capabilities of all players.
>>>>>>>> 
>>>>>>>> -- Justin
>>>>>>>> 
>>>>>>>> On 08/19/2013 11:15 AM, Anthony Nadalin wrote:
>>>>>>>>> There are proposals out there that are trying to solve the same
>>>> problem, but in different ways, so I would not say that they are trying
>>>> to solve different use cases. I do think that we need to make sure that
>>>> whatever proposal we select it needs to have a wide range of use cases
>>>> it solves, not just a single use case as the more solutions this group
>>>> produces the more confused folks will be
>>>>>>>>> 
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: [e-mail] [mailto:[e-mail]] On
>>>> Behalf Of Justin Richer
>>>>>>>>> Sent: Monday, August 19, 2013 7:27 AM
>>>>>>>>> To: Phil Hunt
>>>>>>>>> Cc: oauth mailing list
>>>>>>>>> Subject: Re: [OAUTH-WG] Dynamic Client Registration Conference
>>>> Call: Thu 22 Aug, 2pm PDT
>>>>>>>>> 
>>>>>>>>> I agree that dynamic registration isn't needed to solve *all* of
>>>> the different use cases. It solves its set of specific problems (and
>>>> does so well, if you ask me), but there are and will always be things
>>>> that it won't work for, and that's fine. That's why I've suggested
>>>> under a separate thread that the other drafts go forward separately and
>>>> that DynReg not be hung up on them. We're fundamentally solving
>>>> different use cases, and there is no magic solution that will solve all
>>>> the problems at once.
>>>>>>>>> 
>>>>>>>>> -- Justin
>>>>>>>>> 
>>>>>>>>> On 08/18/2013 08:15 PM, Phil Hunt wrote:
>>>>>>>>>> I think we should start by reviewing use cases taxonomy.
>>>>>>>>>> 
>>>>>>>>>> Then a discussion on any client_id assumptions and actual
>>>> requirements for each client case. Why is registration needed for each
>>>> case?
>>>>>>>>>> 
>>>>>>>>>> The statement can solve some complication but should be put in
>>>> context of use cases.
>>>>>>>>>> 
>>>>>>>>>> Phil
>>>>>>>>>> 
>>>>>>>>>> On 2013-08-18, at 15:01, Hannes Tschofenig
>>>> <[e-mail]> wrote:
>>>>>>>>>> 
>>>>>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>>>>>> Hash: SHA512
>>>>>>>>>>> 
>>>>>>>>>>> - -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>>>>>> Hash: SHA512
>>>>>>>>>>> 
>>>>>>>>>>> Based on your feedback via the poll let us start with August
>>>> 22nd with the first conference call. I will distribute the conference
>>>> call details on Tuesday.
>>>>>>>>>>> 
>>>>>>>>>>> Let us talk about the agenda. There were several items brought
>>>> up in
>>>>>>>>>>> discussions, namely
>>>>>>>>>>> 
>>>>>>>>>>> * Software assertions / software statements
>>>>>>>>>>> 
>>>>>>>>>>> We briefly discussed this topic at the IETF OAuth session but
>>>> we may need more time to understand the implications for the current
>>>> dynamic client registration document:
>>>> http://www.ietf.org/proceedings/87/slides/slides-87-oauth-2.pptx
>>>>>>>>>>> 
>>>>>>>>>>> * SCIM vs. current dynamic client registration approach for
>>>>>>>>>>> interacting with the client configuration endpoint
>>>>>>>>>>> 
>>>>>>>>>>> In the past we said that it would be fine to have a profile
>>>> defined in SCIM to provide the dynamic client registration for those
>>>> who implement SCIM and want to manage clients also using SCIM. It
>>>> might, however, be useful to compare the two approaches in detail to
>>>> see what the differences are.
>>>>>>>>>>> 
>>>>>>>>>>> * Interactions with the client registration endpoint
>>>>>>>>>>> 
>>>>>>>>>>> Justin added some "life cycle" description to the document to
>>>> motivate some of the design decisions. Maybe we need to discuss those
>>>> in more detail and add further text.
>>>>>>>>>>> Additional text could come from the NIST Blue Button / Green
>>>> Button usage.
>>>>>>>>>>> 
>>>>>>>>>>> * Aspects that allow servers to store less / no state
>>>>>>>>>>> 
>>>>>>>>>>> - - From the discussions on the list it was not clear whether
>>>> this is actually accomplishable with the current version of OAuth. We
>>>> could explore this new requirement and try to get a better
>>>> understanding how much this relates to dynamic client registration and
>>>> to what extend it requires changes to the core spec.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> What would you like to start with? Other topics you would like
>>>> to bring up?
>>>>>>>>>>> - -----BEGIN PGP SIGNATURE-----
>>>>>>>>>>> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
>>>>>>>>>>> Comment: GPGTools - http://gpgtools.org
>>>> iQEcBAEBCgAGBQJSEULvAAoJEGhJURNOOiAtttEH/Aogg8Q/R/L9/mzU05IQbnze
>>>> AdXB1ZvySkV3jZT4I5shmP7hQr6mc6P6UdvyOrSjrvPlBHen55/oa5z7Cwchd1dk
>>>> dcDUEavbodjnm9SrOs0nKaTvdeZimFSBkGMrfhoTYLXpymP24F9PZgwUXdOcFocF
>>>> OiCs3qDajYaA395DCg5+4mOLQQgDnmy4drlgj2NPv1nMBRDBubzgAhJccwF2BLN9
>>>> IW7MAwTEu7vYT/gwIFzriPkui7gYpf8sAqsnzf/z7FtXbsP8imgOKUlQxzZzeSSP
>>>> QEb6+syyMD9Gt6wxQfWzyl5T0bYLP6DQ+ldZR8yGKCwb+2k3LN6Q8bIpj4mIERI=
>>>>>>>>>>> =tkGT
>>>>>>>>>>> - -----END PGP SIGNATURE-----
>>>>>>>>>>> -----BEGIN PGP SIGNATURE-----
>>>>>>>>>>> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
>>>>>>>>>>> Comment: GPGTools - http://gpgtools.org
>>>> iQEcBAEBCgAGBQJSEUQfAAoJEGhJURNOOiAt8wkIAI3xgdsWuOB36KLiMLRUG+Zb
>>>> RvYqV+rOH80m7YVJcdOLjQJcpPqOIBdzq/yuNiAaF1uFJCqBn97ZQ/NLXLNGcg8x
>>>> wI/Laz7kP2U4B2trBTMtAf2wsY9uYw4Eh+eOEDKGF6cmkEzrzrlw4q/Sfu6vy181
>>>> VI+kqwzZ+iYX4iL3NYPlkg3rwF4OZ1v3T08Erg2SPrbmNd1TRfJJU8HrYFEJQo1q
>>>> p0RiLjcFFDCEZs0gDr9zliCXllV7J9h2ttqLq8+xwPATDuO6buQdFS9vZQ8t1u36
>>>> a0FIuy3NM8PQbblC3B5WumUjW4kntLV09ytYV8h6S8C/dgFwMqzAwEAeNx1exyE=
>>>>>>>>>>> =3qNI
>>>>>>>>>>> -----END PGP SIGNATURE-----
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> 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
>>>>> 
>>>>> 
>>>>> Eve Maler                                 
>>>> http://www.xmlgrrl.com/blog
>>>>> [phone]                        
>>>> http://www.twitter.com/xmlgrrl
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth