Hi Phil, Using dyn-reg-14 vocabulary: the BB+ `registration_jwt` is an "initial access token" that's used to perform a "Protected Registration" (see B.2<http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-14#appendix-B.2>of dyn-reg-14).
Does this make sense? (Happy to provide more detail if it would help.) -J On Tue, Aug 20, 2013 at 9:04 AM, Phil Hunt <phil.h...@oracle.com> wrote: > 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
