There are a couple of potential approaches to this. You can either use dynamic
registration to get a new client_id for each instance, or you can tie
instance-specific information to a single client_id.
In the former case, you can protect the registration endpoint with developer
key of some kind
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 you
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
I agree with your assessment here.
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On 2012-10-19, at 11:12 AM, John Bradley 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 ov
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 regi
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
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 al
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 d
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 wrote:
> The client instance registration was something that we discussed and put
> into the openID Connect dynamic clie
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
I have a native app scenario where
- There are multiple app instances
- The same user user can have multiple app instances (phone, tablet)
- I would want to use confidential clients - the native app instance
dynamically receives the client_secret
- There should be a way to limit the number of app i
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
On Thu, Oct 18, 2012 at
Pedro,
AFAIK this is still a TODO within the current charter.
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
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 i
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
14 matches
Mail list logo
