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

[Torsten Lodderstedt <[e-mail]>]

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.

>
>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.

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