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

[Josh Mandel <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
>
>
>
>
>
>
>
> On 2013-08-20, at 8:30 AM, Josh Mandel <[e-mail]> 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 <[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
>>
>
>
>