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

[George Fletcher <[e-mail]>]

 From a use case perspective... do we need to take this back to the 
level of why do we need to do registration in the first place?

Current assumed reasons for registration:
1. callback URL specification as some Authorization Services require 
pre-registration
2. client meta-data data (useful for UI presentation to the user during 
authorization flows)
3. client identification often necessary for managing policy decisions
4. others?

[Personally, the concept of an application being able to access a 
protected resource without registering at all is orthogonal to this 
issue of dynamic registration and should be solved separately.]

Different cases for authorization policy
1. User-centric where the user explicitly grants a given app some set of 
limited authorizations
2. AS controlled authorization where the AS grants a set of limited 
authorizations based on the identification of the client outside of the 
user's control
3. Enterprise/policy based authorizations. These may include the user 
identity but are not dependent on the user's consent.
4. Others?

 From my perspective... here are the use cases we want to support

1. Client application can obtain an instance specific client 
identification and secret. This is for deployment of mobile apps.
2. Client applications can easily register with multiple Authorization 
Servers. For consumer based applications this will be more and more 
critical as application level protocols standardize on OAuth2 for API 
security.
3. Consumer friendly experience... meaning that the consumer can easily 
understand what client is requesting which scopes so that the user can 
make an informed decision.
4. Server side revocation of both client instances and classes of clients

One of my concerns with moving solely to the "assertion/statement" model 
is that it requires the client to send a lot of state with every request 
which increases the number of bytes on the wire. Given that all of this 
data is still just bearer data (must be protected by the client)... 
doing an upfront registration with the larger set of data and then using 
a reference (client_id) to that data makes a lot of sense to me.

Sorry for the mishmash of thoughts:)

George

On 8/20/13 11:12 AM, Phil Hunt 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
>
>

-- 
George Fletcher <http://connect.me/gffletch>