The "jwks" meta-data parameter may also be required for some of the Proof of
Possession flows. Allowing a client to register its public key is important
for reducing the number of long term symetric keys that need to be maintained.
On Apr 30, 2014, at 5:15 PM, Brian Campbell wrote:
> As Mike
Somewhat related is the client_secret_expires_at parameter. It seems a
little odd to have that in this protocol that offers no way to deal with
the expiration other than a completely new reregistration. It also seems
like it should be more general than just the expiration of the secret and
apply to
As Mike and Torsten have said, and for the same reasons, I would also like
to see the "jwks" metadata parameter added.
On Sun, Apr 20, 2014 at 4:14 AM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:
> Hi all,
>
> I also believe both documents should be merged.
>
> Nevertheless, here are
Hi all,
I also believe both documents should be merged.
Nevertheless, here are my comments on the current drafts:
* OAuth 2.0 Dynamic Client Registration Core Protocol
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-16
1.2. Terminology
" Multiple instances of the same piece of client
April 06, 2014 12:59 AM
To: Bill Mills
Cc: oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] Working Group Last Call on Dynamic Client Registration
Documents
I think it is at the discretion of the actual deployment whether clients may
dynamically register or not (meaning the
lationship with.
>
> -- Mike
>
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt
> Sent: Sunday, April 06, 2014 12:59 AM
> To: Bill Mills
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH
pre-existing relationship with.
-- Mike
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt
Sent: Sunday, April 06, 2014 12:59 AM
To: Bill Mills
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Working Group Last Call
Hmm. I think this issue is self evident to the developer
If they have obtained a client id through developer registration (current
typical oauth) they are good to go.
IOW If you have a client id issued out of band you are good to go.
Otherwise look for dyn reg or some other method. This likel
I think it is at the discretion of the actual deployment whether clients may
dynamically register or not (meaning they need to go through some oob
mechanism). Protocols utilizing OAuth could make it part of their mandatory to
implement features - in the same way OIDC does.
Best regards,
Torsten
annes Tschofenig; oauth@ietf.org
Subject: RE: [OAUTH-WG] Working Group Last Call on Dynamic Client Registration
Documents
If these are going to be combined then a draft should be produced and then a
decision should be made once everyone has a chance to review
-Original Message-
From:
heers,
-- Mike
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Bill Mills
Sent: Saturday, April 05, 2014 10:13 PM
To: Torsten Lodderstedt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Working Group Last Call on Dynamic Client Registration
Documents
To me the fundamental questi
To me the fundamental question of whether a client has to be registered in each
place it is used is quite significant. We don't address the problem and have
not discussed it enough.
-bill
On Friday, April 4, 2014 11:39 PM, Torsten Lodderstedt
wrote:
Hi Bill,
which scalability problem are y
; oauth@ietf.org
Subject: Re: [OAUTH-WG] Working Group Last Call on Dynamic Client Registration
Documents
I would combine these two documents, with no normative changes. This would be
a convenience for implementers. And the metadata values that are currently
optional would remain optional.
I would
Hi Bill,
I believe Torsten is right. Most of the discussion in London was focused
on the management API rather than the core/meta-data docs.
Unfortunately, in our agenda we lumped both of these topics together.
There wasn't much disagreement on the core/meta-data docs.
As I wrote on the mailing l
Hi Bill,
which scalability problem are you referring to? As far as I remember there were
issues around the management API but not the core protocol.
regards,
Torsten.
> Am 04.04.2014 um 18:41 schrieb Bill Mills :
>
> Given the fundamental scalability problem we discussed in London do we really
I would combine these two documents, with no normative changes. This would be
a convenience for implementers. And the metadata values that are currently
optional would remain optional.
I would also add an optional "jwks" metadata member, paralleling this addition
in OpenID Connect Registratio
Given the fundamental scalability problem we discussed in London do we really
feel we're ready?
On Friday, April 4, 2014 3:07 AM, Hannes Tschofenig
wrote:
Hi all,
This is a Last Call for comments on the dynamic client registration
documents:
* OAuth 2.0 Dynamic Client Registration Core Proto
I believe the two documents should be merged back into one, keeping the
same functionality. It doesn't help developers to split them out like
this and it doesn't change the modularity of the implementation at all
to have things listed in separate documents.
I would really like to see actual co
18 matches
Mail list logo
