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
Hi George,
I see two distinct areas of interoperability, which
are Client-AS and AS-RS. Dynamic client registration belongs to
Client-AS whereas JWT AS-RS communication belong to the later area.
OAuth 2.0 currently (not fully) covers Client-AS and does not address
AS-RS. In my opinion,
In Connect's dynamic client authentication we optionally allow for
authenticated clients to register.
The idea is that you can have a master token pre provisioned in an app and then
use that to get an individual client ID and client secret for a native app on a
per instance basis.
This is
Hi Torsten,
I guess I worry that trying to solve all the use cases that get pulled
in with dynamic client registration will take a long time. I've been
involved with both the UMA work and the OpenID Connect work regarding
dynamic client registration and some reasonable constraints and
FYI, the OpenID Connect dynamic client registration spec is at
http://openid.net/specs/openid-connect-registration-1_0.html. You can find
points to all the Connect specs at http://openid.net/connect/.
-- Mike
From:
Would the plan be for the Connect Registration spec to be submitted to IETF so
they can become WG drafts?
The spec seems like a good starting point.
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On 2012-03-22, at 8:34 AM, Mike Jones wrote:
FYI, the OpenID Connect
I really like the 5 items limit. If people are uncomfortable about leaving so
many items off the charter, the charter can have an explicit line item for
further charter review once all work has been completed. This is the default
process anyway, but people here tend to be over sensitive, you
It is a OIDF spec at the moment. We don't have any plan to submit it
currently.
If there is a WG desire for that to happen the OIDF board would have to discuss
making a submission.
All in all I don't know that it is worth the IPR Lawyer time, as Thomas has a
quite similar ID Submission.
I've been told recently that they have to be published as I-Ds to be
considered. The secretariat even clamped down on referencing external blog
posts never-mind external specs. :-) The new SCIM BoF which hopes to get a WG
formed had to arrange to get the simplecloud.info specs submitted as
I agree with John that submitting the OpenID Connect dynamic client
registration spec to the IETF would make no sense. It is intentionally
specific to the requirements of the Connect use case.
I sent the link to it only so people could compare them, if interested.
-- Mike
I think it's a matter of politics and semantics: The real question is
what do we officially build the IETF version off of? The WG can't
officially start with the OIDF document due to IETF process, which makes
sense. But there's nothing that says we can't start with Thomas's draft
and be
I agree that a goal of any OAuth dynamic registration work should be that it
can be extended to meet the requirements of the OpenID Connect use case. I'm
sure that extensions would be required, as the Connect registration spec
intentionally has knowledge built into it that is specific to
Am happy to start with Thomas's draft.
Going forwards it seems hard to be 'heavily influenced' by things 'we cannot
consider'. :-)
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On 2012-03-22, at 10:35 AM, Justin Richer wrote:
I think it's a matter of politics and
13 matches
Mail list logo
