Subject: [OAUTH-WG] Dynamic registration of client application instances

From: Pedro Felix <[email-masked]>
Date: Thu, 18 Oct 2012 17:06:16 +0100

Hi,

Where can I find more information about the dynamic registration of client
application instances?
The idea is that each installed application instance has a different id,
eventually related to the "general" application id.

It also would be interesting if this instance id was the result of an
activation process, where the instance is attached to a device or to an
user (e.g. confimed email address).

Thanks
Pedro

---

From: Phil Hunt <[email-masked]>
Date: Thu, 18 Oct 2012 09:59:14 -0700

Pedro,

AFAIK this is still a TODO within the current charter.

Phil

@independentid
www.independentid.com
[email-masked]

On 2012-10-18, at 9:06 AM, Pedro Felix wrote:

> Hi,
> 
> Where can I find more information about the dynamic registration of client application instances?
> The idea is that each installed application instance has a different id, eventually related to the "general" application id.
> 
> It also would be interesting if this instance id was the result of an activation process, where the instance is attached to a device or to an user (e.g. confimed email address).
> 
> Thanks
> Pedro
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Pedro Felix <[email-masked]>
Date: Fri, 19 Oct 2012 15:47:41 +0100

Thanks for the response.

I know that this area is work in progress. However, I've looked into
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-00 and didn't found
much about this subject.
What is the best place to follow this discussion? This mailing list?

Thanks
Pedro

---

From: John Bradley <[email-masked]>
Date: Fri, 19 Oct 2012 12:24:45 -0300

The client instance registration was something that we discussed and put into the openID Connect dynamic client registration but has not yet been put back into the UMA draft.

http://openid.bitbucket.org/openid-connect-registration-1_0.html

The basic idea is that you can bake a access token into client code and that client then uses that to get a unique clientID and secret/register public key.

There was a long discussion about this at a IIW about a year ago.   

In some of the native apps projects I am looking at that are not openID connect related we are looking at doing the same thing to differentiate instances of clients.

John B.

On 2012-10-19, at 11:47 AM, Pedro Felix <[email-masked]> wrote:

> Thanks for the response.
> 
> I know that this area is work in progress. However, I've looked into http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-00 and didn't found much about this subject.

---

From: Pedro Felix <[email-masked]>
Date: Fri, 19 Oct 2012 17:00:37 +0100

And what if the client instance is also connected to some verifiable user
attribute, such as an email?
Is this a bad idea?

Pedro

On Fri, Oct 19, 2012 at 4:24 PM, John Bradley <[email-masked]> wrote:

> The client instance registration was something that we discussed and put
> into the openID Connect dynamic client registration but has not yet been
> put back into the UMA draft.
>
> The basic idea is that you can bake a access token into client code and
> that client then uses that to get a unique clientID and secret/register
> public key.
>
> In some of the native apps projects I am looking at that are not openID
> connect related we are looking at doing the same thing to differentiate
> instances of clients.
>
> John B.
>
>
>
>> > The idea is that each installed application instance has a different
>> id, eventually related to the "general" application id.
>> >

---

From: prateek mishra <[email-masked]>
Date: Fri, 19 Oct 2012 12:26:20 -0400

Pedro - the best way to move this forward is to make a proposal or 
describe some use-cases.

My own guess is that we also need a broader discussion of different 
client-types and their deployment models.
For example, there are clients that are delivered  through a secured 
process to tablets or devices or desktops. Another category of
clients are services hosted by an application server, these have quite 
different characteristics as well.

- prateek

-

> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-00 and didn't 
> found much about this subject.
> On Thu, Oct 18, 2012 at 5:59 PM, Phil Hunt <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Pedro,
>
>     www.independentid.com <http://www.independentid.com>
>     [email-masked] <mailto:[email-masked]>
>
>
>
>
>
>     > The idea is that each installed application instance has a
>     different id, eventually related to the "general" application id.
>     >
>     > It also would be interesting if this instance id was the result
>     of an activation process, where the instance is attached to a
>     device or to an user (e.g. confimed email address).
>     >
>     > Thanks
>     > Pedro
>     >
>     > [email-masked] <mailto:[email-masked]>

---

From: George Fletcher <[email-masked]>
Date: Fri, 19 Oct 2012 12:40:06 -0400

I think it's an interesting idea... I'm just not sure how to tie the 
dynamic client registration to a verified user email address. To get a 
verified email address, most OAuth2 flows require the client_id to be 
already provisioned.

I do agree that from the AS/OP perspective, we don't want to allow 
unlimited client registrations. This could be it's own form of DoS 
attack. I suppose if the client has a verifiable token containing the 
user attributes, that could be passed optionally to the dynamic client 
registration flow. How the client got the verifiable token could be left 
out of scope.

There are probably other ways to protect against abuse and they will 
likely be different from OP to OP for a while, until some best practices 
are established.

Thanks,
George

On 10/19/12 12:00 PM, Pedro Felix wrote:
> And what if the client instance is also connected to some verifiable 
> user attribute, such as an email?
> Is this a bad idea?
>
> Pedro
>
> On Fri, Oct 19, 2012 at 4:24 PM, John Bradley <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     The client instance registration was something that we discussed
>     and put into the openID Connect dynamic client registration but
>     has not yet been put back into the UMA draft.
>
>     The basic idea is that you can bake a access token into client
>     code and that client then uses that to get a unique clientID and
>     secret/register public key.
>
>     In some of the native apps projects I am looking at that are not
>     openID connect related we are looking at doing the same thing to
>     differentiate instances of clients.
>
>     John B.
>
>
>
>     On 2012-10-19, at 11:47 AM, Pedro Felix <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>>     Thanks for the response.
>>
>>     I know that this area is work in progress. However, I've looked
>>     into http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-00 and
>>     didn't found much about this subject.
>>         www.independentid.com <http://www.independentid.com/>
>>         > Where can I find more information about the dynamic
>>         registration of client application instances?
>>         > It also would be interesting if this instance id was the
>>         result of an activation process, where the instance is
>>         attached to a device or to an user (e.g. confimed email address).
>>         >
>>         > Thanks
>>         > Pedro
>>         >

---

From: Phil Hunt <[email-masked]>
Date: Fri, 19 Oct 2012 10:39:20 -0700

Consider that the issues comes from 2 angles:
1. The desire to distinguish between instances of a client app (e.g. on mobile phones)
2. The desire for the client to register with particular instances of a resource service.

The objective:  to establish a unique credential that binds a particular client instance (or set of clients) with a particular resource service provider.

I note that, per John's suggestion, this is something like what OpenID Connect attempted to solve with their dynamic registration draft.

As further input, during the review of the OAuth Threat Model, there was significant inquires and discussion about how to assess the legitimacy or authenticity of a piece of client software. Though we didn't solve it, there was a lot of requests for finding a way to authenticate client software as simply being the one made by its developer.

Therefore, I think there is requirement to be able to authenticate software (at some level) that is part of the dynamic registration process.

I think there is a few of steps in dynamic registration.
1. A method to authenticate the software. Is it signed by its publisher?  If the resource being accessed is developed by a single publisher, has the client been registered with the publisher? Hypothetical examples of this might be clients designed to work with MS Exchange, or Oracle CRM.
2. Optionally establishing a means to distinguish one client instance from another.
3. Dynamically issuing the client with a credential (which may or may not be instance specific) to use with a particular instance of a resource authorization server.

Regarding step 1, I note that in the case OpenID Connect, there is no single place to even register a client as there is with proprietary APIs. Not sure if software signing can work here. The same problem will emerge with any standards based API (e.g. such as SCIM).  This is why I think dynamic registration is of broad interest in the standards community beyond just OpenID.

Phil

@independentid
www.independentid.com
[email-masked]

On 2012-10-19, at 9:40 AM, George Fletcher wrote:

> I think it's an interesting idea... I'm just not sure how to tie the dynamic client registration to a verified user email address. To get a verified email address, most OAuth2 flows require the client_id to be already provisioned. 
> 
> I do agree that from the AS/OP perspective, we don't want to allow unlimited client registrations. This could be it's own form of DoS attack. I suppose if the client has a verifiable token containing the user attributes, that could be passed optionally to the dynamic client registration flow. How the client got the verifiable token could be left out of scope.
> 
> There are probably other ways to protect against abuse and they will likely be different from OP to OP for a while, until some best practices are established.
> 
> Thanks,
> George
> 
>> And what if the client instance is also connected to some verifiable user attribute, such as an email?
>> Is this a bad idea?
>> 
>> Pedro
>>

---

From: John Bradley <[email-masked]>
Date: Fri, 19 Oct 2012 15:12:46 -0300

It would be nice if software signing could work, however verifying that over a network connection without some sort of OS level TPM seems overly ambitious.

We were not trying to solve that problem with connect, only find a way that we could provision a secret for native apps.

Certainly the registration token can be stolen and faked by a rogue app.  

However with a good app it lets you get a unique client secret for the app or register a public key (something perhaps useful for Proof of possession tokens as well)

For web server clients this is not a big deal because registration is a one tie thing.

For native apps on phones etc having every one with the same clientID and password is not a good thing.

John B.

---

From: Phil Hunt <[email-masked]>
Date: Fri, 19 Oct 2012 11:35:24 -0700

I agree with your assessment here.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Nat Sakimura <[email-masked]>
Date: Sun, 21 Oct 2012 13:37:46 +0900

On the instance identification purpose, it may be interesting to generate a
key-pair and register the public key out of it to the server, similar to
what we do in the case of Self-Issued OP in OpenID Connect.

So, the app will have the client_id, which is pre-provisioned to the same
app as a "class", and the app, when first registering itself to the server
will generate the "instance id" which is tied to the secret key that is
typically stored in key-chain or similar devices.

Note that the key generation has to be done for each server or server
groups as otherwise it will become trivial to track the user across.

Nat

On Sat, Oct 20, 2012 at 3:35 AM, Phil Hunt <[email-masked]> wrote:

> It would be nice if software signing could work, however verifying that
> over a network connection without some sort of OS level TPM seems overly
> ambitious.
>
> We were not trying to solve that problem with connect, only find a way
> that we could provision a secret for native apps.
>
> However with a good app it lets you get a unique client secret for the app
> or register a public key (something perhaps useful for Proof of possession
> tokens as well)
>
> The objective:  to establish a unique credential that binds a particular
> client instance (or set of clients) with a particular resource service
> provider.
>
> I note that, per John's suggestion, this is something like what OpenID
> Connect attempted to solve with their dynamic registration draft.
>
> As further input, during the review of the OAuth Threat Model, there was
> significant inquires and discussion about how to assess the legitimacy or
> authenticity of a piece of client software. Though we didn't solve it,
> there was a lot of requests for finding a way to authenticate client
> software as simply being the one made by its developer.
>
> Therefore, I think there is requirement to be able to authenticate
> software (at some level) that is part of the dynamic registration process.
>
> 1. A method to authenticate the software. Is it signed by its publisher?
>  If the resource being accessed is developed by a single publisher, has the
> client been registered with the publisher? Hypothetical examples of this
> might be clients designed to work with MS Exchange, or Oracle CRM.
> 3. Dynamically issuing the client with a credential (which may or may not
> be instance specific) to use with a particular instance of a resource
> authorization server.
>
> Regarding step 1, I note that in the case OpenID Connect, there is no
> single place to even register a client as there is with proprietary APIs.
> Not sure if software signing can work here. The same problem will emerge
> with any standards based API (e.g. such as SCIM).  This is why I think
> dynamic registration is of broad interest in the standards community beyond
> just OpenID.
>
> Phil
>
> @independentid
> www.independentid.com
> [email-masked]
>
>
>
>
>
> unlimited client registrations. This could be it's own form of DoS attack.
> I suppose if the client has a verifiable token containing the user
> attributes, that could be passed optionally to the dynamic client
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: "Richer, Justin P." <[email-masked]>
Date: Wed, 24 Oct 2012 06:33:13 +0000

There's also this means of providing identifying instance information for a single client registration:

http://tools.ietf.org/html/draft-richer-oauth-instance-00

This is solving a different need and can be used in tandem with, or in lieu of, the dynamic registration per-client, depending on your use case. Sometimes you're happy with just one registered client_id but want to track multiple copies of it getting tokens -- that's what this extension is for.

 -- Justin

On Oct 20, 2012, at 9:37 PM, Nat Sakimura wrote:

On the instance identification purpose, it may be interesting to generate a key-pair and register the public key out of it to the server, similar to what we do in the case of Self-Issued OP in OpenID Connect.

So, the app will have the client_id, which is pre-provisioned to the same app as a "class", and the app, when first registering itself to the server will generate the "instance id" which is tied to the secret key that is typically stored in key-chain or similar devices.

Note that the key generation has to be done for each server or server groups as otherwise it will become trivial to track the user across.

Nat

On Sat, Oct 20, 2012 at 3:35 AM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:
I agree with your assessment here.

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

John B.

On 2012-10-19, at 2:39 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

Thanks,
George

Pedro

On Fri, Oct 19, 2012 at 4:24 PM, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:
The client instance registration was something that we discussed and put into the openID Connect dynamic client registration but has not yet been put back into the UMA draft.

John B.

On 2012-10-19, at 11:47 AM, Pedro Felix <[email-masked]<mailto:[email-masked]>> wrote:

Thanks for the response.

Thanks
Pedro

On Thu, Oct 18, 2012 at 5:59 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:
Pedro,

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

On 2012-10-18, at 9:06 AM, Pedro Felix wrote:

> [email-masked]<mailto:[email-masked]>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth