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

[Justin Richer <[e-mail]>]

The registration_jwt captures many of the same things that the proposed 
"software statement" does, and it's presented as an initial access 
token. The Provider then parses this token and uses the BB+ Discovery 
system to validate the token against the Registry that issued it. This 
is what we talked about at IIW this year (and what I had suggested to 
Morteza for his use case), and it's all detailed on the same page that 
Josh linked:

http://blue-button.github.io/blue-button-plus-pull/#registration-trusted

When designing the BB+ registration system (which directly influenced 
the OAuth DynReg current draft, as I've said many times), we were 
careful about where we drew the lines dividing the two systems. You'll 
note that the BB+ "Open Registration" is exactly the OAuth DynReg 
registration, and that the "Trusted Registration" builds directly on top 
of that, but requires an assertion format (JWT), a discovery system, a 
manual pre-registration step, and a policy that vets a network of 
Registries to manage everything. We decided fairly early on that there 
was too much baggage to bring the full BB+ Trusted Registration over to 
a general use case, but I've continually pointed out its existence and 
asked you (Phil) to read it when you've brought up the software assertions.

  -- Justin

On 08/20/2013 12:04 PM, Phil Hunt 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 <http://www.independentid.com>
> [e-mail] <mailto:[e-mail]>
>
>
>
>
>
>
>
> On 2013-08-20, at 8:30 AM, Josh Mandel <[e-mail] 
> <mailto:[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] 
>> <mailto:[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] <mailto:[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] <mailto:[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 <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 <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] <mailto:[e-mail]>
>>     >>> https://www.ietf.org/mailman/listinfo/oauth
>>     >> _______________________________________________
>>     >> OAuth mailing list
>>     >> [e-mail] <mailto:[e-mail]>
>>     >> https://www.ietf.org/mailman/listinfo/oauth
>>     _______________________________________________
>>     OAuth mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth