See below Phil
On 2013-08-19, at 22:34, Torsten Lodderstedt <tors...@lodderstedt.net> 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...@xmlgrrl.com> 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 <jric...@mitre.org> 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 <jric...@mitre.org> 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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] 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 >> <hannes.tschofe...@gmx.net> 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 >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> Eve Maler >> http://www.xmlgrrl.com/blog >>> +1 425 345 6756 >> http://www.twitter.com/xmlgrrl >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
