Hi John,
I don't think dynamic registration completely removes the need for a
public client, that can't keep secrets.
I don't get this argument. In my opinion, there are two use cases,
which currently motivate usage of public clients and none of them is
about "keeping secrets".
1) native apps - There is no mechanism for securely _provisioning_
those clients with client secrets. So it does not make sense to use
secrets for authenticating them. Dynamic client registration would allow
them to obtain client id and secret on activation/installation. The
security of the respective secret is the same as for refresh tokens. So
either both can be protected appropriately or none of them. Please note:
I'm not talking about trust in the identity/authenticity of the
particular app installation. I'm just talking about simplifying the
OAuth flows and description. Today an AS needs to support the refresh
tokens or resource owner grant type for both confidential and public
clients in order to also support native apps.
2) implicit grant - here, public clients are used because the protocol
design itself does not allows for validating client secrets. Obviously,
digital signature would help but make the protocol more difficult to
use.
Basically, dynamic client registration allows a client to bind to an AS
at runtime. That's what it makes so valuable with respect to
interoperatibility. Whether the client just registers meta data or also
obtains a secret is another aspect but not the only one.
regards,
Torsten.
While we did do dynamic client registration for Connect that is a
more constrained use case.
I would put JWT and AS-RS communication as higher priorities than
dynamic registration.
Partially because they are more self contained issues.
John B.
On 2012-03-21, at 4:35 PM, Torsten Lodderstedt wrote:
In my opinion, dynamic client registration would allow us to drop
public client thus simplifying the core spec.
regards,
Torsten.
Am 15.03.2012 16:00, schrieb Eran Hammer:
I believe most do, except for the dynamic client registration. I
don't have strong objections to it, but it is the least important and
least defined / deployed proposal on the list. The AS->RS work is
probably simpler and more useful at this point.
EH
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf
Of Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Thursday, March 15, 2012 4:47 AM
To: ext Blaine Cook; Hannes Tschofenig
Cc: [email protected]
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
Hi Blaine,
These are indeed good requirements you stated below.
When you look at the list of topics do you think that the proposed
items
indeed fulfill them?
Ciao
Hannes
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf
Of ext Blaine Cook
Sent: Thursday, March 15, 2012 1:31 PM
To: Hannes Tschofenig
Cc: [email protected] WG
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
On 14 March 2012 20:21, Hannes Tschofenig
<[email protected]>
wrote:
So, here is a proposal:
[Editor's Note: New work for the group. 5 items maximum! ]
Aug. 2012 Submit 'Token Revocation' to the IESG for
consideration
as a Proposed Standard
Nov. 2012 Submit 'JSON Web Token (JWT)' to the IESG for
consideration as a Proposed Standard
Nov. 2012 Submit 'JSON Web Token (JWT) Bearer Token Profiles
for
OAuth 2.0' to the IESG for consideration
Jan. 2013 Submit 'OAuth Dynamic Client Registration Protocol'
to
the IESG for consideration as a Proposed Standard
Sep. 2012 Submit 'OAuth Use Cases' to the IESG for
consideration
as an Informational RFC
This looks great to me.
I have serious concerns about feature-creep, and think that the
OAuth
WG should strongly limit its purview to these issues. In general,
I
think it prudent for this working group in particular to consider
standardisation of work only under the following criteria:
1. Proposals must have a direct relationship to the mechanism of
OAuth
(and not, specifically, bound to an application-level protocol).
2. Proposals must have significant adoption in both enterprise
and
startup environments.
3. Any proposal must be driven based on a consideration of the
different approaches, as adopted in the wild, and strive to be a
better synthesis of those approaches, not a means to an end.
These are the constraints with which I started the OAuth project,
and
they're more relevant than ever. I'd hate to see OAuth fail in
the end
because of a WS-*-like death by standards-pile-on.
b.
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
