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

[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