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

[Josh Mandel <[e-mail]>]

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 <[e-mail]> 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)" <
> [e-mail]> 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 <[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
>