Neither registration_access_token nor registration_client_uri are mentioned in
core-16. They're both required in the management draft, and it makes sense
there. If you're not implementing the management draft (or you've got your own
thing for that), then you don't return either of them.
-- Jus
Where is registration_client_uri in the spec?
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On 2014-03-06, at 4:00 PM, Anthony Nadalin wrote:
> Same is true for the registration_client_uri as I may not need/want this,
> should be optional
>
> From: OAuth [mailto:oauth-boun
Same is true for the registration_client_uri as I may not need/want this,
should be optional
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin
Sent: Thursday, March 6, 2014 7:02 AM
To: Mike Jones; oauth@ietf.org list
Subject: Re: [OAUTH-WG] Working Group Versions of Refacto
So the current core makes the registration_access_token required and there are
open registration endpoints, so this should be optional, there are also cases
where the client_id is signed and that becomes the right to the registration
endpoint
From: OAuth [mailto:oauth-boun...@ietf.org] On Beha
Hi all,
several OAuth folks met today to talk about the next steps regarding the
OAuth dynamic client registration management API.
At the end of our short lunch chat I asked each participant individually
what they think should be done next. Here are the notes I took.
Phil: We need to document wh
I'm getting the impression you don't want the particular meta data that's been
specified. Hence why you want the separate spec.
What's the issue? Maybe we should change the metadata?
I'd rather not see people do similar things that are done different ways.
Whatever we do is already breaking fo
+1 should not be merged
-Original Message-
From: Mike Jones
Sent: Thursday, March 6, 2014 5:19 AM
To: Anthony Nadalin; tors...@lodderstedt.net; oauth@ietf.org
Subject: RE: [OAUTH-WG] IETF #89 OAuth Meeting Notes
I also disagree with moving "scope" into the core registration spec. The
If metadata is optional i don't see the issue with it being in core.
Then again i don't think metadata should be in a separate draft.
Phil
> On Mar 6, 2014, at 13:18, Mike Jones wrote:
>
> I also disagree with moving "scope" into the core registration spec. The
> metadata values in the cor
I would like everything from the metadata spec moved to core with the same
optionality that it has in the two documents, in order to facilitate
readability and ease of use for developers. I would be fine with having it in
listed in two separate subsections.
Also, so it doesn't get lost, we shou
I also disagree with moving "scope" into the core registration spec. The
metadata values in the core spec are those that are essential to use to achieve
registration. Those in the metadata spec are those that are useful in some
applications but not needed by some others. "scope" is of the sec
While I'm sure we can and will discuss the organization of the documents
for some
time, I wanted to reiterate that I believe the client credential management
part of this needs to be reevaluated (not just reorganized).
On Thu, Mar 6, 2014 at 9:37 AM, Anthony Nadalin wrote:
> I'm not convinced th
I'm not convinced that scope should be in core
-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of tors...@lodderstedt.net
Sent: Thursday, March 6, 2014 12:38 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] IETF #89 OAuth Meeting Notes
Hi,
regarding dynamic client r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 3/4/14, 6:04 PM, Hannes Tschofenig wrote:
> Hi all,
>
> at today's OAuth meeting I suggested to get together during the
> week to continue our conversation about
> draft-ietf-oauth-dyn-reg-management-00, which dominated our
> conversation at the
Hi,
regarding dynamic client registration: it has been suggested to merge
core and meta data, or at least move some elements (such as scopes) to
the core spec. Would you please add this?
regards,
Torsten.
Am 05.03.2014 13:43, schrieb Hannes Tschofenig:
Hi al
here are the notes from the OAu
14 matches
Mail list logo
