A very minor update incorporating some of the changes suggested by Hannes
(mostly wording or document structure - the actual content of the document is
effectively the same).
-- Justin
On Jan 15, 2015, at 4:39 PM, internet-dra...@ietf.org wrote:
A New Internet-Draft is available from the
A very minor update incorporating some of the changes suggested by Hannes
(mostly wording or document structure - the actual content of the document is
effectively the same).
-- Justin
On Jan 15, 2015, at 4:39 PM, internet-dra...@ietf.org wrote:
A new version (-22) has been submitted for
It also does not make sense to
show the developer in the box together with the client since the
developer does not execute a protocol exchange with the client
registration endpoint.
That's not true, a developer (person or organization) could very easily be
using the dynamic registration
I've read this over a little while ago, and I think it's ready to go. The
actual core mechanism is pretty straight forward.
-- Justin
On Dec 29, 2014, at 12:46 PM, Bill Mills
wmills_92...@yahoo.commailto:wmills_92...@yahoo.com wrote:
No other comments on this? Any It's ready to go.?
On
than that, ready to go to the RFC state if you ask me.
Le mar. 23 déc. 2014 19:02, Richer, Justin P.
jric...@mitre.orgmailto:jric...@mitre.org a écrit :
This draft makes two changes:
- Removal of the resource_id input parameter, whose purpose has been largely
supplanted by requiring
This draft makes two changes:
- Removal of the resource_id input parameter, whose purpose has been largely
supplanted by requiring authorization to call the introspection endpoint. I
also don't know of any implementations that make use of this parameter. If
there's later consensus on defining
Yes it did, as part of the PoP suite. It's the current stab at an HTTP
presentation mechanism for PoP tokens.
-- Justin
On Dec 22, 2014, at 11:21 AM, Bill Mills
wmills_92...@yahoo.commailto:wmills_92...@yahoo.com wrote:
Did this get adopted as a WG item already and I missed it?
On Monday,
was in the middle of rewriting that part when I
got distracted.
-- Justin
A last note on the content itself: +1, I don't think I have any further comment
to make.
On Thu Dec 04 2014 at 01:05:07 Richer, Justin P.
jric...@mitre.orgmailto:jric...@mitre.org wrote:
Small update
On Dec 3, 2014, at 9:03 AM, Thomas Broyer
t.bro...@gmail.commailto:t.bro...@gmail.com wrote:
On Tue Dec 02 2014 at 19:53:27 Richer, Justin P.
jric...@mitre.orgmailto:jric...@mitre.org wrote:
Thomas, thanks for the review. Responses inline.
On Dec 2, 2014, at 11:08 AM, Thomas Broyer
t.bro
Small update to the Introspection draft incorporating comments from the past
couple days. I haven't put together the IANA considerations section that will
tie the introspection claims to the JWT registry yet, but that's the intent.
Please check the diffs, read the new version, and continue to
However, I think it's very clear how PoP tokens would work. You send the
value returned as the access_token in the token endpoint response,
which is effectively the public portion of the PoP token. Just like a
bearer token, this value is passed as-is from the client to the RS and
would be
/14 15:36, Richer, Justin P. wrote:
However, I think it's very clear how PoP tokens would work. You send the
value returned as the access_token in the token endpoint response,
which is effectively the public portion of the PoP token. Just like a
bearer token, this value is passed as-is from
No, this isn't an appropriate mapping in this case, especially if the
introspection endpoint is itself OAuth protected. You need to be able to
differentiate between the token being asked about and the token authorizing the
question. These error codes apply to the latter and should not be
The call to introspection has a TLS requirement, but the call to the RS
wouldn't necessarily have that requirement. The signature and the token
identifier are two different things. The identifier doesn't do an attacker any
good on its own without the verifiable signature that's associated with
of?
On Tuesday, December 2, 2014 11:05 AM, Richer, Justin P.
jric...@mitre.orgmailto:jric...@mitre.org wrote:
The call to introspection has a TLS requirement, but the call to the RS
wouldn't necessarily have that requirement. The signature and the token
identifier are two different things
Kathleen, thanks for your review. Responses inline.
On Nov 19, 2014, at 9:56 PM, Kathleen Moriarty
kathleen.moriarty.i...@gmail.commailto:kathleen.moriarty.i...@gmail.com
wrote:
Hi,
I reviewed draft-Ietf-oauth-dyn-reg-20 and have the following questions before
we move this to IETF last call.
There's a new working group document where this component *could* be captured
(and I would argue it should), and that's:
https://tools.ietf.org/wg/oauth/draft-ietf-oauth-token-exchange/
However, at the moment it's more concerned with the semantically-aware
assertion swap instead of an opaque
tors...@lodderstedt.net wrote:
Hi all,
I just read the document. It explains the situation,
challenges/threats, and options very clear and readable.
So +1 for publishing it soon.
kind regards,
Torsten.
Am 28.10.2014 00:21, schrieb Richer, Justin P.:
I've been incorporating peoples
don't think changes needed.
Cloud Identity's software implements an earlier version, as far as I remember.
I will check and let you know.
Kind regards,
Maciej
From: Richer, Justin P. [jric...@mitre.orgmailto:jric...@mitre.org]
Sent: Friday, September 12, 2014 2:56 PM
This *also* needed to be sent to the WG.
Begin forwarded message:
From: John Bradley ve7...@ve7jtb.commailto:ve7...@ve7jtb.com
Subject: Re: Shepherd Writeup for draft-ietf-oauth-dyn-reg-management-05
Date: September 12, 2014 at 10:47:54 AM EDT
To: Michael Jones
I've been incorporating peoples' feedback into the proposed oauth.net page, and
the current state is here:
https://github.com/jricher/oauth.net/blob/authentication/articles/authentication.php
Commentary has slowed down and I think the document's in reasonable. I would
like to publish this as a
. (the
client has a per-OP configurable unique user id claim name anyhow).
On 10/16/14, 7:27 PM, Richer, Justin P. wrote:
Ah yes, good catch! If only someone would put up a webpage describing
the difference between authorization and authentication and why people
need to stop confusing the two.
Oh
other flows for this.
Hans.
On 10/20/14, 9:04 PM, Richer, Justin P. wrote:
This is actually one of the sticky bits that I've tried to address in the
document itself -- I've seen apps that assume that if they're given an
access token that can be used to fetch profile information then the user
On Oct 17, 2014, at 8:25 AM, Sergey Beryozkin sberyoz...@gmail.com wrote:
+1. I'm finding this write-up summarizing the OAuth2 and Authentication
'situation' perfectly. It does help.
Minor suggestions/questions:
- might make sense to point out that an id_token can be linked to the access
- should a few words be reserved for the client credentials flow - this is
of course not a mainstream OAuth2 nor its related to OIDC but it is all
about the authentication IMHO, the clients get their tokens by simply
getting authenticated, and as far as legacy (code) clients are concerned
On Oct 17, 2014, at 10:57 AM, Sergey Beryozkin sberyoz...@gmail.com wrote:
Hi,
On 17/10/14 15:09, Richer, Justin P. wrote:
- should a few words be reserved for the client credentials flow - this
is of course not a mainstream OAuth2 nor its related to OIDC but it is
all about
Ah yes, good catch! If only someone would put up a webpage describing the
difference between authorization and authentication and why people need to stop
confusing the two.
Oh wait...
On Oct 16, 2014, at 1:06 PM, Hans Zandbelt hzandb...@pingidentity.com wrote:
About the write-up: at the end
Those interested in helping edit the text directly can follow along on this
GitHub fork:
https://github.com/jricher/oauth.net/tree/authentication
Once a reasonable number of eyes have seen that page, we'll get it published
onto oauth.net. Aaron Parecki has offered to add a Draft banner to the
I agree with Phil on this one (hey, it happens!): this is a classic example of
having one piece of software and many instances of it talking to many different
service providers. Each of those pairings is going to need to agree on a client
ID, and one would hope a client secret or equivalent.
In BlueButton+ REST, we defined a matrix of client types based on whether the
client could keep a configuration-time secret (the registration_jwt,
predecessor to the software_statement) and a particular kind of runtime
secret (the client secret) in addition to the token. That matrix is defined
is unrestricted; any other
form would involve some form of admin/user approval at registration
time, overcoming the concern at authorization time: there's no
auto-redirect flow possible for unknown clients.
Hans.
On 9/4/14, 9:04 AM, Richer, Justin P. wrote:
I think this advice isn't a bad idea
It used to be simply expires_at but after discussion on the list it was
changed to client_secret_expires_at, since the client's secret is the most
likely part to expire and need to be refreshed. Of course this refresh makes
the most sense if you're implementing the management spec where you can
According to the guidelines here:
https://www.ietf.org/iesg/informational-vs-experimental.html
And the discussion in Toronto, it's clearly experimental.
-- Justin
On Sep 11, 2014, at 10:36 AM, Anthony Nadalin tony...@microsoft.com wrote:
Is experimental the correct classification? Maybe
would say neither fits. Ugh.
Phil
On Sep 11, 2014, at 8:01, Richer, Justin P. jric...@mitre.org wrote:
According to the guidelines here:
https://www.ietf.org/iesg/informational-vs-experimental.html
And the discussion in Toronto, it's clearly experimental.
-- Justin
On Sep 11, 2014
I think this advice isn't a bad idea, though it's of course up to the AS what
an untrusted client really is. In practice, this is something that was
registered by a non-sysadmin type person, either a dynamically registered
client or something available through self-service registration of some
Neither of these are authentication (they don't tell the client or business
logic server who the user is or if they're still there), they're authorization
and they're both well within the scope of OAuth.
The first one is a redirect flow, that actually works (in OAuth) like this:
1) Clients
registered clients where registration is unrestricted; any other form
would involve some form of admin/user approval at registration time,
overcoming the concern at authorization time: there's no auto-redirect
flow possible for unknown clients.
Hans.
On 9/4/14, 9:04 AM, Richer, Justin P
As John points out, that could be either resource owner or client credentials
flow, depending on the use case.
-- Justin
On Sep 4, 2014, at 11:43 AM, Sergey Beryozkin sberyoz...@gmail.com wrote:
Hi Justin
On 04/09/14 13:15, Richer, Justin P. wrote:
Neither of these are authentication
New revision with minor editorial changes, thanks to some good feedback from my
colleague, Amanda Anganes. Nothing substantive should have changed.
-- Justin
On Aug 26, 2014, at 10:36 AM, internet-dra...@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
New revision with minor editorial changes thanks to some good feedback from my
colleague, Amanda Anganes. Phil Hunt has been removed as an author, as per his
request. No substantive changes otherwise.
-- Justin
On Aug 26, 2014, at 10:37 AM, internet-dra...@ietf.org wrote:
A New
This update includes the editorial changes discussed in Toronto and on the
list, mostly around description of a handful of metadata fields. We added the
discussion about redirect URIs to the security considerations section, and
removed the application_type metadata parameter. We also added
As discussed in Toronto, this draft has been marked Experimental. No other
substantive changes have been made.
-- Justin
On Aug 5, 2014, at 3:56 PM, internet-dra...@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item
This value was introduced in -18, and it's a direct port from OpenID Connect.
It was never in the OAuth Dynamic Registration spec, and though it has been in
the OpenID Connect Dynamic Registration spec for a very long time, I think it
was a mistake to add it in for several reasons:
First, the
it, we may as well
keep it.
Nat
2014-07-09 7:54 GMT+09:00 Richer, Justin P.
jric...@mitre.orgmailto:jric...@mitre.org:
This value was introduced in -18, and it's a direct port from OpenID Connect.
It was never in the OAuth Dynamic Registration spec, and though it has been in
the OpenID Connect
In draft -18, we clarified the optionality of the client metadata parameters in
§ 2 with new text, including the sentences:
The implementation and use of all client metadata fields is OPTIONAL, other
than redirect_uris.
redirect_uris (...) Authorization servers MUST implement support for
I've updated the introspection draft based on the handful of comments that I
received from -05 to allow these discussions to be incorporated into the
discussion going forward:
http://tools.ietf.org/id/draft-richer-oauth-introspection-06.html
-- Justin
redirect-based
grant types MUST implement support for this metadata value and clients that use
redirect-based grant types MUST use this parameter.
-- Mike
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Richer, Justin P.
Sent
Seems like a reasonable extension to me, in that it shouldn't break things,
really. Is the suggestion to define a particular member for other stuff or to
state that you're allowed to add other stuff inside the payload object?
But on the other hand, I'm wondering why other parts of the protocol
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
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.
--
I can do that, too.
-- Justin
From: OAuth [oauth-boun...@ietf.org] on behalf of Phil Hunt
[phil.h...@oracle.com]
Sent: Tuesday, March 04, 2014 1:13 PM
To: Hannes Tschofenig
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Discussion about Dynamic Client
Expiration of drafts happens automatically after a set amount of time has
passed without edits. There haven't needed to be any edits to the introspection
draft in many months (apart from a couple typos), so I haven't updated it.
-- Justin
From:
All output will be published back to the list for further discussion and
approval in all cases.
-- Justin
On Nov 5, 2013, at 3:28 PM, Matt Miller (mamille2) mamil...@cisco.com
wrote:
On Nov 5, 2013, at 3:01 PM, Richer, Justin P. jric...@mitre.org wrote:
At the end of Monday's WG
, Richer, Justin P. jric...@mitre.org
wrote:
At the end of Monday's WG session here at IETF, Derek suggested that
several of us who are here ought to get together and hash out some
detailed solutions to Dyn-Reg and related issues in person while we
have the opportunity. As such, I suggest that those
Since the client isn't really supposed to be poking around inside of the
client_id anyway, I think that JWS is a reasonable starting place, with JWE if
you want to actively hide something inside of the client_id from the client
(and browser and other parties that see the client_id). Most of the
Hannes,
There are a number of major use cases and expectations that I've kept in mind
throughout the development of this protocol. Some of the fallout of this is
captured in appendix B of the current draft, but I'd be happy to write them out
here:
First, the use cases of OpenID Connect and
The software statement does make sense and we could use it in BB+ to take the
place of the registration_jwt, even though I'm not really in favor of inventing
yet another mechanism for presenting an assertion to an OAuth-protected
endpoint.
The association draft is in many ways semantically
On Oct 25, 2013, at 1:47 PM, Todd W Lainhart
lainh...@us.ibm.commailto:lainh...@us.ibm.com
wrote:
I'm working off this document for our client registration:
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-14
Section 4 - Client Configuration Endpoint says this:
The client MUST use its
On Oct 23, 2013, at 5:27 PM, Thomas Broyer
t.bro...@gmail.commailto:t.bro...@gmail.com
wrote:
On Wed, Oct 23, 2013 at 9:22 PM, Richer, Justin P.
jric...@mitre.orgmailto:jric...@mitre.org wrote:
Hi Thomas,
You're right in that the introspection process is about getting meta data about
Hi Thomas,
You're right in that the introspection process is about getting meta data about
a particular token by making an authenticated call. It does reveal a lot of
information about the token -- because that's exactly the point of the
protocol. :)
If the PR is compromised, then the
As it says in the draft, this could be used with dynamic registration, manual
registration, or any other method of registration. How you get the client_id
and the nature of the client_id are orthogonal to each other.
As such, you could easily issue this structured/signed stateless client_id in
If you have a confidential client using a traditional symmetric secret, from
the client's perspective you wouldn't pack the secret into the client_id with
this method any more than you would pack it into the client_id using a normal
method -- at least as far as the client is concerned, they're
After last week's design team call, at Derek's suggestion, I took time today to
refactor the Dynamic Registration draft into two pieces: core and
management. The former contains the definition of the Registration Endpoint
and the semantics surrounding that, the latter contains the Client
Phil, I'm not objecting to it! I never have been! I've been saying all along
it's a proper extension to the base dynamic registration spec because it
defines optional functionality in addition to said base spec. Why do you object
to it being an extension?
-- Justin
On Aug 22, 2013, at 4:43
.
Justin is correct.
John B.
On 2013-07-30, at 5:30 PM, Phil Hunt
phil.h...@oracle.commailto:phil.h...@oracle.com wrote:
Forgot reply all.
Phil
Begin forwarded message:
From: Phil Hunt phil.h...@oracle.commailto:phil.h...@oracle.com
Date: 30 July, 2013 17:25:46 GMT+02:00
To: Richer, Justin P
From what I read, you've defined something that uses an OAuth 2 code flow to
get an extra token which is specified as a JWT. You named it session_token
instead of id_token, and you've left off the User Information Endpoint --
but other than that, this is exactly the Basic Client for OpenID
is clearest.
From an ietf perspective the concern is improper use of the 6749 for authn. Is
this a bug or gap we need to address?
Phil
On 2013-07-30, at 16:46, Richer, Justin P.
jric...@mitre.orgmailto:jric...@mitre.org wrote:
From what I read, you've defined something that uses an OAuth 2 code
or need the userinfo endpoint.
Phil
On 2013-07-30, at 17:17, Richer, Justin P.
jric...@mitre.orgmailto:jric...@mitre.org wrote:
What do you mean? You absolutely can implement a compliant OIDC server nearly
as simply as this. The things that you're missing I think are necessary for
basic
.
-- Justin
On Jul 30, 2013, at 12:57 PM, Paul Madsen
paul.mad...@gmail.commailto:paul.mad...@gmail.com
wrote:
I always think I pretty much understand OIDC until I see the specs list
On 7/30/13 12:39 PM, Brian Campbell wrote:
Yes, that.
On Tue, Jul 30, 2013 at 4:46 PM, Richer, Justin P.
jric
Phil, thanks very much for writing this up and submitting it. As we had said on
the design team call, I think it will make a lot of sense to keep both this
draft and the existing dyn-reg in parallel as much as possible, and to abstract
out elements with general applicability (like the software
Amanda, thanks for the review -- comments inline.
On Jun 4, 2013, at 1:56 PM, Anganes, Amanda L
aanga...@mitre.orgmailto:aanga...@mitre.org wrote:
[[Apologies if you receive this twice, I accidentally sent this from one of my
other email addresses this morning (Outlook seems to have been
, understood.
best regards,
Torsten.
-- Justin
best regards,
Torsten.
Am 24.05.2013 23:10, schrieb Richer, Justin P.:
New Dynamic Registration draft is published, incorporating much of
the discussion from the group this week.
Some normative changes that should have minimal
From: Phil Hunt [phil.h...@oracle.com]
Sent: Thursday, May 30, 2013 7:31 PM
To: Richer, Justin P.
Cc: John Bradley; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt
Phil
On 2013-05-30, at 16:11, Richer, Justin P.
jric
As I recall, the argument was that without this, someone could just keep
fishing at the token revocation endpoint for valid tokens. Though thinking
about it now, even if you did get a token was valid response, the token
wouldn't be valid anymore and it wouldn't do you much good.
It's possible
I agree with Josh, and I believe that this kind of application should
definitely be supported. One of my goals with the Dynamic Registration draft
was to make it so that it could be used for all the various flavors of OAuth
that people are using today. But that said, I'm not at all against
I completely disagree with this assessment. The latest draft (which was just
posted) has new language describing what this token is and what it's for, and I
hope that will clear things up. But even so, let me try to address your
concerns in-line.
On May 24, 2013, at 4:02 PM, Phil Hunt
New Dynamic Registration draft is published, incorporating much of the
discussion from the group this week.
Some normative changes that should have minimal impact:
- expires_at is now client_secret_expires_at
- issued_at is now client_id_issued_at
- creation of an IANA registry for
, Justin P.
jric...@mitre.orgmailto:jric...@mitre.org wrote:
I agree with Josh, and I believe that this kind of application should
definitely be supported. One of my goals with the Dynamic Registration draft
was to make it so that it could be used for all the various flavors of OAuth
that people
I have already been using an approach like this for all of the drafts that I
edit, most notably the DynReg WG document and both the Introspection and
Chaining individual submissions. I run everything through my GitHub repository
here:
https://github.com/jricher/oauth-spec/
I use the issue
The biggest problem with this attack is the passing of the access token to a
backend server (and its subsequent passing of that token to someone else) and
the assumption that the presentation of the access token means that the user is
authenticated and present. It simply doesn't mean that, and
Phil, many thanks for the extremely thorough review! It is very useful indeed.
My comments and responses to each point are inline.
On May 15, 2013, at 4:30 PM, Phil Hunt
phil.h...@oracle.commailto:phil.h...@oracle.com wrote:
It seems unfortunate that I have not gotten a chance to get into this
Hooray! Congratulations to the whole working group!
-- Justin
On May 15, 2013, at 2:34 PM, Hannes Tschofenig hannes.tschofe...@gmx.net
wrote:
That's great to hear.
Hope you have taken some pictures from the awards ceremony.
On 05/15/2013 08:24 PM, Mike Jones wrote:
I’m pleased to
So if that's the case -- you've got a client that can't keep a secret that has
a secret -- you do one of the normal auth methods (like client_secret_basic)
and call it a day. I don't think it makes any sense, and the language below is
really less about client secrets and more about assertions
it does. If servers just ignore the param most of the time, what value is
there?
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On 2013-05-06, at 8:39 AM, Richer, Justin P. wrote:
In spite of what John seems to think, that dependency was never
A true public client doesn't have a client_secret or its equivalent, so it
would have token_endpoint_auth_method = none. A confidential client can't use
the implicit flow (since you can't send a client_secret to the auth endpoint),
so there's a bit of overlap there.
Would it be useful to have
On 2013-05-05, at 12:52 PM, Richer, Justin P. wrote:
Handful of minor changes in this revision, including tightening the language
around scopes and adding an absolute-URI based mechanism for extending
token_endpoint_auth_method (no registry, still). No normative changes beyond
Sep 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the IESG
for consideration as a Proposed Standard
-- Justin, do you think that this document can be completed in September or
earlier?
Earlier, I'd say. In my opinion, the document is feature complete and I have no
Handful of minor changes in this revision, including tightening the language
around scopes and adding an absolute-URI based mechanism for extending
token_endpoint_auth_method (no registry, still). No normative changes beyond
removing an unreachable error state. (Thanks, Nov.) Please check the
I agree that we shouldn't try to solve scope in registration. I think it
makes the most sense for registration to be as hands-off about scope as core
OAuth is.
-- Justin
On Apr 18, 2013, at 12:18 PM, Phil Hunt
phil.h...@oracle.commailto:phil.h...@oracle.com wrote:
There are a number of
It was brought up at the in-person meeting today that we'll want to consider
issues around internationalization and localization of human-readable fields
like client_name in the client registration. Which is to say: if a client
supports ten languages and wants to present itself in ten
-registration-1_0-15.html#client-metadata
and the examples.
client_name: My Example,
client_name#ja-Jpan-JP:クライアント名,
On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin P.
jric...@mitre.orgmailto:jric...@mitre.org wrote:
It was brought up at the in-person meeting today that we'll want
:26 PM, Richer, Justin P.
jric...@mitre.orgmailto:jric...@mitre.org wrote:
My concern with this is that OIDC can get away with defining this
multi-language structure because it defines the mechanism once (in Messages)
and applies it to all user-readable strings throughout the whole application
From my read, it's a combination of browser bugs (it only affects Chrome) and
Facebook's insistence on using the Implicit flow for everything.
While I don't at all care for the sky is falling rhetoric that seems to
follow OAuth2, the author has some good suggestions for implementations:
It's a pretty good shortcut to not have to deal with request tokens, to be able
to use scopes, to have access to client assertions and other methods of client
auth, and not have to do signing when talking to the AS. It's no shortcut when
talking to the RS, that's for sure.
-- Justin
On Feb
Everyone, there's a new draft of DynReg up on the tracker. This draft tries to
codify the discussions so far from this week into something we can all read.
There are still plenty of open discussion points and items up for debate.
Please read through this latest draft and see what's changed and
I got the same reading of the list as you, and I could go either way. I believe
we absolutely must pick one or the other though.
If anyone has thoughts on the matter one way or the other, please speak up. The
options are:
1) scopes are returned as a JSON array (current introspection text)
2)
On Feb 3, 2013, at 8:01 AM, Torsten Lodderstedt tors...@lodderstedt.net wrote:
Hi all,
before I publish a new revision of the draft, I would like to sort out the
following issues and would like to ask you for your feedback.
- Authorization vs. access grant vs. authorization grant: I
On Feb 4, 2013, at 3:57 PM, George Fletcher gffle...@aol.com
wrote:
On 2/4/13 3:41 PM, Richer, Justin P. wrote:
On Feb 3, 2013, at 8:01 AM, Torsten Lodderstedt tors...@lodderstedt.net
wrote:
- invalid_token error code: I propose to use the new error code
invalid_parameter
For history, the original UMA registration spec from whence this all grew was
JSON-in and JSON-out. It's feeling like this is coming back around.
Pro:
- more REST-ish (particularly if we use real REST style like URL templates and
verbs)
- consistent data structures
- possible use of rich
Additionally:
This begs the question, why not just do SCIM here? CloudFoundry's UAA has a
SCIM class for OAuth clients that they use for dynamic registration today.
-- Justin
On Feb 4, 2013, at 4:25 PM, Mike Jones
michael.jo...@microsoft.commailto:michael.jo...@microsoft.com
wrote:
Now
1 - 100 of 182 matches
Mail list logo
