Josh, I think BlueButton is an important example of use.
Tell us more about registration_jwt (which is not part of dyn reg). Phil @independentid www.independentid.com phil.h...@oracle.com On 2013-08-20, at 8:30 AM, Josh Mandel <jman...@gmail.com> wrote: > The group may be interested in bits of the following classification that we > put together for BlueButton+: > http://blue-button.github.io/blue-button-plus-pull/#client-types > > Here, we classified apps according to > 1. whether they can protect a `client_secret` and > 2. whether they can protect a `registration_jwt` (issued by a third party > and presented by the client to the registration endpoint at registration time) > > We used this classification with the current dyn-reg draft, in order to give > implementers a concrete idea about how policy might vary according to client > type. Part of why this works nicely for BB+ is that we actually get to > control (well, specify!) policy within the BB+ network. > > -Josh > > > On Tue, Aug 20, 2013 at 8:12 AM, Phil Hunt <phil.h...@oracle.com> wrote: > By taxonomy i mean the distinct types of clients and associations. > > Eg > - javascript > - native app > - web app > - apps that associate to one endpoint vs those the register with multiple > based on events > - perm vs temporary associations > > There are probably more. > > As Torsten mentions one of the most important factors is first how the server > recognizes the client that is registering. It needs to do this to set or > associate policy. > > What does a service provider gain if it has no information about clients? The > downside of issuing random client_ids is little or no policy based access > control and resource depletion. > > So we have to ask ourselves in each case why register? What is achieved for > each side? Client id is a major factor but it is not THE factor. > > Phil > > On 2013-08-20, at 7:51, ", Hannes (NSN - FI/Espoo)" > <hannes.tschofe...@nsn.com> wrote: > > > Hi Phil, > > > > > >> I think we should start by reviewing use cases taxonomy. > > > > > > What do you mean by "use cases taxonomy"? What exactly would we discuss > > under that item? > > > >> > >> Then a discussion on any client_id assumptions and actual requirements > >> for each client case. Why is registration needed for each case? > > > > I guess you are bringing the use case to the table where there is no client > > id needed (?) or where the client id is provided by yet another party > > (other than the one running the AS). > > > >> > >> The statement can solve some complication but should be put in context > >> of use cases. > > > > Ciao > > Hannes > > > >> 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
