John, what you've described is more or less manual registration as it
stands today. But with Dynamic Registration and an open registration
endpoint, a smartphone client (for instance) actually *can* be a
confidential client now. It can store runtime secrets, and can therefore
protect a client_s
Dynamic registration provides:
1 A client_id
2 (Optionally) a client secret that is used at the token endpoint per OAuth. to
authenticate the associated client_id
3 a URI that can be used to update the client_id (this is a REST concept and
may be thought of as a instance of client_id rather than
Dynamic registration provides:
1 A client_id
2 (Optionally) a client secret that is used at the token endpoint per OAuth. to
authenticate the associated client_id
3 a URI that can be used to update the client_id (this is a REST concept and
may be thought of as a instance of client_id rather than
Phil
On 2013-05-20, at 8:45, Justin Richer wrote:
>
> On 05/17/2013 07:29 PM, Phil Hunt wrote:
>> He's saying every client gets a registration token and a client token.
> What's a "client token", exactly? There are three potential places for OAuth
> tokens in and around dynamic registration,
On 05/17/2013 07:29 PM, Phil Hunt wrote:
He's saying every client gets a registration token and a client token.
What's a "client token", exactly? There are three potential places for
OAuth tokens in and around dynamic registration, and none of them are
called "client token".
1) The registra
John
Thanks. This is *very* helpful. I will consider for next week.
Phil
On 2013-05-17, at 23:56, John Bradley wrote:
> From what I have seen deployed, there are four common flows for registration.
>
> 1 2 developer uses a tool to register a client ID and place that in the
> client code for
From what I have seen deployed, there are four common flows for registration.
1 2 developer uses a tool to register a client ID and place that in the client
code for deployment of a native App that is distributed via an app store for a
3rd party API. The developer may later need to make change
From what I have seen deployed, there are four common flows for registration.
1 2 developer uses a tool to register a client ID and place that in the client
code for deployment of a native App that is distributed via an app store for a
3rd party API. The developer may later need to make change
John,
Thanks for jumping in.
1. I do buy the implied argument that some client credential types do expire
(eg. bearer assertions). Therefore the expiry issue has to be dealt with. I
would prefer to handle this by allowing an exception whereby expired assertions
could be used to re-register (
-Original Message-
From: Phil Hunt [mailto:phil.h...@oracle.com]
Sent: Friday, May 17, 2013 12:01 PM
To: Donald F Coffin
Cc: Mike Jones; oauth@ietf.org
Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access
Token - draft-ietf-oauth-dyn-reg-10
That is incorrect. A client
.
-- Mike
From: Phil Hunt [mailto:phil.h...@oracle.com]
Sent: Friday, May 17, 2013 2:57 AM
To: Mike Jones
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access
Token - draft-ietf-oauth-dyn-reg-10
Or, are you saying reg access token is
; From: Mike Jones [mailto:michael.jo...@microsoft.com]
> Sent: Thursday, May 16, 2013 3:27 PM
> To: Phil Hunt; oauth@ietf.org WG
> Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access
> Token - draft-ietf-oauth-dyn-reg-10
>
> This is nothing more than an
michael.jo...@microsoft.com]
Sent: Thursday, May 16, 2013 3:27 PM
To: Phil Hunt; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access
Token - draft-ietf-oauth-dyn-reg-10
This is nothing more than an RFC 6750 bearer token. These can expire, as
explained in
1 No reasonable security profile is going to let you use the same symmetric
password over long time periods. It will be brute forced given enough time.
The rotation time will depend on entropy and the rate an attacker can submit
attempts.I would expect profiles to look at SP-800-63 for gu
Justin,
Your reason was you copied connect. Ok. I was looking for a technical reason.
A security reason.
BTW. Mike Jones says expiry wasn't the reason.
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On 2013-05-17, at 9:01 AM, Justin Richer wrote:
> The separation betw
The separation between these two is necessary: Not all clients have
client_secret, and you want the lifecycle/management of the registration
to be protected. This is what the registration access token was made
for. In older versions of Connect's registration, the client_secret was
forced on all
resent the client's registration.
>
> -- Mike
>
> From: Phil Hunt
> Sent: 5/17/2013 9:53 AM
> To: Mike Jones
> Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access
> Token - draft-ietf-oauth-dyn-reg-10
>
> Well why not just use the client toke
-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Phil
Hunt
Sent: Thursday, May 16, 2013 2:35 PM
To: oauth@ietf.org WG
Subject: [OAUTH-WG] Client Credential Expiry and new Registration Access Token
- draft-ietf-oauth-dyn-reg-10
All,
In the dynamic registration draft, a new token ty
All,
In the dynamic registration draft, a new token type is defined called the
"registration access token". Its use is intended to facilitate clients being
able to update their registration and obtain new client credentials over time.
The client credential is issued on completion of the initia
19 matches
Mail list logo
