Seems reasonable to me, can you suggest language to add in the
capability? Would it require an IANA registry? Right now there isn't any
other place that enumerates the various methods that a client can use to
access the token endpoint.
-- Justin
On 04/24/2013 04:17 PM, Phil Hunt wrote:
For
You are correct that the idea behind the scope parameter at
registration is a constraint on authorization-time scopes that are made
available. It's both a means for the client to request a set of valid
scopes and for the server to provision (and echo back to the client) a
set of valid scopes.
15, 2013 6:54 AM, Justin Richer jric...@mitre.org
mailto:jric...@mitre.org wrote:
You are correct that the idea behind the scope parameter at
registration is a constraint on authorization-time scopes that are
made available. It's both a means for the client to request a set
that I can write code to
implement as specified. -T
On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer jric...@mitre.org
mailto:jric...@mitre.org wrote:
Scopes aren't meant to be interoperable between services since
they're necessarily API-specific. The only interoperable bit
endpoint with an exact string-match metric and set-based logic.
-- Justin
On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer jric...@mitre.org
mailto:jric...@mitre.org wrote:
What would you suggest for wording here, then? Keeping in mind
that we cannot (and don't want to) prohibit
...@ietf.org] *On
Behalf Of *Justin Richer
*Sent:* Monday, April 15, 2013 8:05 AM
*To:* Tim Bray; oauth@ietf.org
*Subject:* Re: [OAUTH-WG] Registration: Scope Values
On 04/15/2013 10:52 AM, Tim Bray wrote:
I’d use the existing wording; it’s perfectly clear. Failing that, if
there’s strong demand
This is a question better directed at Facebook's developers community
since it's more specific to Facebook's API. I would suggest posting your
question to StackOverflow:
http://stackoverflow.com/
-- Justin
On 04/08/2013 07:39 AM, ECS ACCENTURE wrote:
Hi,
I am following this link :
Currently, the Dynamic Registration draft defines a scope value as
part of the client metadata table, with the following definition:
scope
OPTIONAL. Space separated list of scope values (as described in
OAuth 2.0Section 3.3 [RFC6749]
Phone: (949) 636-8571
Email: donald.cof...@reminetworks.com
mailto:donald.cof...@reminetworks.com
*From:*Justin Richer [mailto:jric...@mitre.org]
*Sent:* Friday, April 12, 2013 11:25 AM
*To:* oauth@ietf.org
*Subject:* [OAUTH-WG] Registration: Scope Values
Currently, the Dynamic Registration
Hi Stephen,
I didn't respond as I didn't have anything to add to your comments, but
what little details I have are inline.
On 04/12/2013 04:53 PM, Stephen Farrell wrote:
Hi,
I'm surprised there've been no responses. I thought
there was more interest in this one.
Ta,
S.
On 04/09/2013
?
Thanks
--
nov
On 2013/03/30, at 5:53, Justin Richer jric...@mitre.org wrote:
New dynamic registration draft is published. Biggest changes here are the
internationalization/localization capabilities that are now applicable to
human-readable client metadata fields.
-- Justin
On 03/29/2013 04
.
(assuming you don't want to use 404 for security reason)
The editor's note is enough detail for the reason of using 401.
Using 403, it's like the token is valid, but the ghost client has no
permission..?
On 2013/04/02, at 2:04, Justin Richer jric...@mitre.org wrote:
If the access token isn't
the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : OAuth 2.0 Dynamic Client Registration Protocol
Author(s) : Justin Richer
John Bradley
:*oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On
Behalf Of *Justin Richer
*Sent:* Friday, 22 March 2013 5:15 AM
*To:* oauth@ietf.org WG
*Subject:* Re: [OAUTH-WG] Registration: Internationalization of
Human-Readable names
We discussed this issue on the OpenID Connect WG call
This approach is what we've implemented in a few places, most notably on
the hReader iOS app (code is in some branch or fork of
https://github.com/projecthreader/hReader, I'm told it's going to be
pulled into that main branch soon though). Here we pre-register the
hReader app with a single
] *On
Behalf Of *Justin Richer
*Sent:* Thursday, March 14, 2013 8:02 AM
*To:* George Fletcher
*Cc:* oauth@ietf.org WG
*Subject:* Re: [OAUTH-WG] Registration: Internationalization of
Human-Readable names
On the surface this does simplify things, but the issue I forsee with
it is that I want
PM, Mike Jones wrote:
How would you do this instead then?
From: Justin Richer
Sent: 3/20/2013 10:25 AM
To: Mike Jones
Cc: George Fletcher; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Registration: Internationalization
.
Title : OAuth 2.0 Dynamic Client Registration Protocol
Author(s) : Justin Richer
John Bradley
Michael B. Jones
Maciej Machulak
Filename: draft-ietf-oauth-dyn-reg-08.txt
match between a request and the data stored at the AS (and out of
scope of the spec).
Thanks,
George
On 3/13/13 10:22 AM, Justin Richer wrote:
So with what little feedback I've gotten, I'm proposing to add text
from the proposed webfinger and OIDC drafts for the hash-based
localization
So with what little feedback I've gotten, I'm proposing to add text from
the proposed webfinger and OIDC drafts for the hash-based localization
of strings, with the following properties:
* All localized versions of fields are fully optional on both client and
server
* If a localized version of a
I hadn't set out to make the introspection draft parallel to the
revocation draft, but I see no reason that these two items couldn't be
incorporated with the same language and semantics.
-- Justin
On 03/07/2013 10:23 AM, Todd W Lainhart wrote:
I forgot to include the token_type_hint
grant_type should have been grant_types, since
the value is a list. We should correct that in the next version of
the spec.
*From:*oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On
Behalf Of *Justin Richer
*Sent:* Wednesday, February 27, 2013 8:00 AM
*To:* oauth@ietf.org
*Subject
Hannes,
The main issue here is that JWT has been built to be used for things
other than OAuth tokens (assertions, for instance), and that the
introspection endpoint is very specifically tied to OAuth. At Torsten's
suggestion, I've tried to align the output of the introspection endpoint
to
anywhere else.
*From:* Justin Richer jric...@mitre.org
*To:* William Mills wmills_92...@yahoo.com
*Cc:* Hannes Tschofenig hannes.tschofe...@gmx.net; oauth@ietf.org
oauth@ietf.org
*Sent:* Thursday, February 28, 2013 9:08 AM
Brian, I think you're conflating two things (and John might be, too). On
the one hand, we've got the JWT document, which talks about what goes
into the token itself. This can be used as an assertion, as an access
token, as a floor wax / dessert topping. JWT doesn't really care, and
this is
There has been some press lately about clients being able to use an
implicit flow to get tokens when they really ought to only use a code
flow, since the security considerations and protections for both are
very different. With this in mind, it makes sense that a dynamically
registered client
Right now, the Dynamic Registration draft has four URLs that deal with
registering public keys for the client:
jwk_uri
jwk_encryption_uri
x509_uri
x509_encryption_uri
These are for use in things like JWK-based assertions for client
authentication and signing/encryption with higher-level
.
Title : OAuth Dynamic Client Registration Protocol
Author(s) : Justin Richer
John Bradley
Michael B. Jones
Maciej Machulak
Filename: draft-ietf-oauth-dyn-reg-06.txt
Pages : 21
Date: 2013-02-15
Abstract:
This specification defines
*From:*Justin Richer [mailto:jric...@mitre.org]
*Sent:* Thursday, February 21, 2013 8:02 AM
*To:* Donald F Coffin
*Cc:* 'Torsten Lodderstedt'; 'John Adkins'; 'Marty Burns'; 'Scott
Crowder'; 'Dave Robin'; 'John Teeter'; pmad...@pingidentity.com;
'Edward Denson'; 'Jay Mitra'; 'Uday Verma'; 'Ray
Message
Subject: New Version Notification for
draft-richer-oauth-introspection-03.txt
Date: Thu, 21 Feb 2013 10:44:15 -0800
From: internet-dra...@ietf.org
To: jric...@mitre.org
A new version of I-D, draft-richer-oauth-introspection-03.txt
has been successfully submitted by Justin
Working Group of the IETF.
Title : OAuth Dynamic Client Registration Protocol
Author(s) : Justin Richer
John Bradley
Michael B. Jones
Maciej Machulak
Filename: draft-ietf-oauth-dyn-reg-06.txt
Pages
F Coffin
*Sent:* Wednesday, February 20, 2013 11:30 AM
*To:* Justin Richer
*Cc:* oauth@ietf.org
*Subject:* [OAUTH-WG] Additional Oauth Dynamic Client Registration
Protocol Information
Justin,
I understand the current Client Registration request and response
information is based on the OPENID
Nat's attack vector presumes lack of logging on the server side, where
doing a delete means that you can no longer see anything about who did
what. You could make the same argument if you have a system where users
can register themselves and delete their accounts at will -- someone
creates a
Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : OAuth Dynamic Client Registration Protocol
Author(s) : Justin Richer
Authorization Protocol Working
Group of the IETF.
Title : OAuth Dynamic Client Registration Protocol
Author(s) : Justin Richer
John Bradley
Michael B. Jones
Maciej Machulak
Filename
least split up lists that are lists
instead of forcing clients and servers to do string parsing.
-- Justin
On 02/11/2013 04:14 PM, Justin Richer wrote:
Draft -05 of OAuth Dynamic Client Registration [1] switched from a
form-encoded input that had been used by drafts -01 through -04 to a
JSON
B.
On 2013-02-13, at 12:00 PM, Justin Richer jric...@mitre.org
mailto:jric...@mitre.org wrote:
Would it be reasonable to mark the PUT and DELETE methods as
optional for the server to implement, but with defined semantics
if they do? I want to keep GET and POST(create
Prateek,
My point was that a public client could very easily and safely be issued
a secret in the form of an OAuth token. This includes any type of
signing key that the MAC/etc token would want to use. What public
client's can't have are configuration-time keys, like a client_secret.
It's
would levee out DELETE.
John B.
On 2013-02-11, at 6:14 PM, Justin Richer jric...@mitre.org wrote:
Draft -05 of OAuth Dynamic Client Registration [1] defines several operations that the client can take on its
behalf as part of the registration process. These boil down to the basic CRUD operations
-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Nat Sakimura
Sent: Tuesday, February 12, 2013 9:15 AM
To: Justin Richer
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management
2013/2/13 Justin Richer jric...@mitre.org:
On 02/12/2013 11:30
, Feb 12, 2013 at 3:19 AM, Justin Richer jric...@mitre.org
mailto:jric...@mitre.org wrote:
On 02/08/2013 12:51 AM, Prabath Siriwardena wrote:
Hi Justin,
I have couple of questions related to valid parameter...
This endpoint can be invoked by the Resource Server in runtime
be an HTTP 201 Created
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.2)
which is supposed to include the location of the newly created resource.
This is a good pattern to follow since, as you say, it does provide
flexibility.
On Feb 11, 2013, at 1:14 PM, Justin Richer jric
of a client and letting them
know they have been turned off for a reason is better than making there
registration disappear.
So for the moment I would levee out DELETE.
John B.
On 2013-02-11, at 6:14 PM, Justin Richer jric...@mitre.org wrote:
Draft -05 of OAuth Dynamic Client Registration [1
- with the operations
being distinguished by whether a refresh_token parameter is present. So
there's a useful OAuth precedent for doing things this way.
-- Mike
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Justin Richer
Sent
.
-- Mike
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Justin Richer
Sent: Monday, February 11, 2013 1:15 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Registration: Endpoint Definition ( operation parameter)
Draft -05 of OAuth
.
-- Mike
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Justin Richer
Sent: Monday, February 11, 2013 1:15 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Registration: HAL _links structure and client self-URL
Draft -05 of OAuth Dynamic Client
comfortable with.
John B.
On 2013-02-12, at 11:25 AM, Justin Richer jric...@mitre.org
mailto:jric...@mitre.org wrote:
I'd be fine with the return from a creation request being a 201
instead of a 200.
-- Justin
On 02/11/2013 06:33 PM, Richard Harrington wrote:
Since the request is an HTTP
it be clear.
-- Justin
On 2013-02-12, at 11:52 AM, Justin Richer jric...@mitre.org wrote:
The problem that I have with always including the client_id is *where* to
include it. Are we talking a query parameter, URI template, or somewhere in the request
body? The latter will only work for POST
are my notes.
Participants:
* John Bradley
* Derek Atkins
* Phil Hunt
* Prateek Mishra
* Hannes Tschofenig
* Mike Jones
* Antonio Sanso
* Justin Richer
Notes:
My slides are available here:
http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
Slide #2 summarizes earlier discussions during
programmers
will certainly goes ???.
We need to check what would be the cases for other scripting languages
before making the final decision.
-- Mike
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Justin Richer
Sent: Monday, February 11
carefully otherwise we start looking like crazies.
If we do it cautiously I am in favour of JSON as input.
John B.
On 2013-02-12, at 4:32 PM, Justin Richer jric...@mitre.org
mailto:jric...@mitre.org wrote:
Thanks for forwarding that, Mike. I'll paste in my response to Nat's
concern here as well
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Nat
Sakimura
Sent: Tuesday, February 12, 2013 9:11 AM
To: Justin Richer; oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: HAL _links structure and client self-URL
Actually, if it is to return
fuse on privacy but ignoring them is probably a mistake.
John B.
On 2013-02-12, at 4:56 PM, Justin Richer jric...@mitre.org wrote:
One question though: How exactly would the client, a software application,
agree to the TOS? Is it supposed to fetch the content of the tos_url and do
some processing
reasonable way. That seems like the most
sensible thing.
However given the number of people talking about encoding it in a form
to get access to it, we should check that it works for everyone.
John B.
On 2013-02-12, at 4:59 PM, Justin Richer jric...@mitre.org
mailto:jric...@mitre.org wrote
As many of you saw, last week I published a draft of the OAuth Dynamic
Client Registration spec [1] that made some fairly serious changes to
how the protocol works. It was my intent to distill many threads of
conversation here on the list into a full, workable protocol with a
concrete document
Draft -05 of OAuth Dynamic Client Registration [1] defines three
fundamental operations that a client can undertake: Client Registration,
Client Update, and Secret Rotation. Each of these actions needs to be
differentiated *somehow* by the client and server as part of the
protocol. Draft -00
Draft -05 of OAuth Dynamic Client Registration [1] switched from a
form-encoded input that had been used by drafts -01 through -04 to a
JSON encoded input that was used originally in -00. Note that all
versions keep JSON-encoded output from all operations.
Pro:
- JSON gives us a rich data
Draft -05 of OAuth Dynamic Client Registration [1] returns a URL pointer
for the client to perform update and secret rotation actions. This
functionality arose from discussions on the list about moving towards a
more RESTful pattern, and Nat Sakimura proposed this approach in the
OpenID
Draft -05 of OAuth Dynamic Client Registration [1] defines a means of
the client requesting a new client_secret (if applicable) and a new
registration_access_token. Client secrets MAY expire after some period
of time, and this method allows for a refresh of that secret. Draft -00
defined no
the
document, can you please suggest text that would help clear the use case
up? I wouldn't want it to be ambiguous.
-- Justin
Thanks regards,
-Prabath
On Thu, Feb 7, 2013 at 10:30 PM, Justin Richer jric...@mitre.org
mailto:jric...@mitre.org wrote:
It validates the token, which
will be first be given to the
working group to adequately discuss them and come to agreement on them.
Thank you,
-- Mike
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Justin Richer
AM, Justin Richer jric...@mitre.org
mailto:jric...@mitre.org wrote:
Updated introspection draft based on recent comments. Changes include:
- scope return parameter now follows RFC6749 format instead of
JSON array
- subject - sub, and audience - aud, to be parallel
with JWT
be used as a way to validate the
token as well. BTW even in this case shouldn't communicate the type of
token to AS? For example in the case of SAML profile - it could be
SAML token..
Thanks regards,
-Prabath
On Thu, Feb 7, 2013 at 8:39 PM, Justin Richer jric...@mitre.org
mailto:jric
These are generally handled through a user interface where the RO is
authenticated directly to the AS, and there's not much need for a
protocol here, in practice. There are larger applications, like UMA,
that have client and PR provisioning that would allow for this to be
managed somewhat
As editor of introspection draft, I would like to see it become a
working group item. After talking with the chairs, there appears to be
some friction with the amount of open working items that the working
group has right now, though, leading to hesitation to add more to our
official plate.
On 02/06/2013 10:13 AM, Prabath Siriwardena wrote:
On Wed, Feb 6, 2013 at 8:19 PM, Justin Richer jric...@mitre.org
mailto:jric...@mitre.org wrote:
These are generally handled through a user interface where the RO
is authenticated directly to the AS, and there's not much need
submitted by Justin Richer and posted to the
IETF repository.
Filename:draft-richer-oauth-introspection
Revision:02
Title: OAuth Token Introspection
Creation date: 2013-02-06
WG ID: Individual Submission
Number of pages: 6
URL:
http://www.ietf.org/internet
of
the IETF.
Title : OAuth Dynamic Client Registration Protocol
Author(s) : Justin Richer
John Bradley
Michael B. Jones
Maciej Machulak
Filename: draft-ietf-oauth-dyn
The counter argument is that if you do something that's half way between
two fairly well-established programming practices, then you can end up
making a strange chimera. I agree that we shouldn't boil the ocean,
but dictating HTTP verb usage on the endpoint is far from that.
The crux of my
Dale is correct, I was misremembering slightly -- UAA does not do what
we would really call dynamic registration with SCIM, but rather does a
static client provisioning using SCIM as the API for provisioning the
client objects. Still, it's a real-life implementation of something
similar that
You know, that works as well. From the client's perspective, the token
isn't good anymore. The client shouldn't care if the token was good in
the first place if it's revoking it.
-- Justin
On 02/05/2013 02:41 PM, Torsten Lodderstedt wrote:
Why not adopting Bill's suggestion and just return
Another very good writeup of this was published recently as well:
http://blogs.msdn.com/b/vbertocci/archive/2013/01/02/oauth-2-0-and-sign-in.aspx
This confusion seems to be a major sticking point among developers.
-- Justin
On 02/05/2013 02:52 PM, Prabath Siriwardena wrote:
FYI and for your
.
For what it's worth, what I was trying to get discussion on was whether
it made sense to make Dynamic Registration look like the rest of OAuth
with separate endpoints, or not.
-- Justin
On Wed, Jan 23, 2013 at 1:05 PM, Justin Richer jric...@mitre.org
mailto:jric...@mitre.org wrote:
I am very
for.
Exactly. And to Bill's point in another thread, we could also register a
link type for each endpoint to help facilitate discovery:
http://tools.ietf.org/html/draft-wmills-oauth-lrdd-06
-- Justin
John B.
On 2013-01-24, at 11:26 AM, Justin Richer jric...@mitre.org wrote:
On 01/24/2013 05:56
seem to be a problem in practice.
-- Mike
*From:*oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On
Behalf Of *Anthony Nadalin
*Sent:* Wednesday, January 30, 2013 1:38 PM
*To:* Justin Richer; Shiu Fun Poon
*Cc:* oauth@ietf.org
*Subject:* Re: [OAUTH-WG] Concerning OAuth introspection
On 01/30/2013 05:24 PM, Sergey Beryozkin wrote:
On 30/01/13 22:08, Justin Richer wrote:
I completely agree that OAuth is not RESTful in any meaningful sense of
the term (and have stated so several times in this thread).
That is fine, this is not the issue, OAuth2 itself does not have
It's not meant to follow the same syntax. Instead, it's making use of
the JSON object structure to avoid additional parsing of the values on
the client side.
We could fairly easily define it as the same space-delimited string if
enough people want to keep the scope format consistent.
--
Not to jump in and answer for Torsten, but I thought I'd offer at least
my understanding of the document:
On 01/23/2013 06:54 PM, Anthony Nadalin wrote:
1. Since not stated I assume that the Revocation Endpoint can exist on a
different server from the Authorization server (or is it
the flexability, to restrict this is nuts as
people won't use it.
-Original Message-
From: Justin Richer [mailto:jric...@mitre.org]
Sent: Wednesday, January 23, 2013 9:27 AM
To: Anthony Nadalin
Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org
Subject: Re: [OAUTH-WG] Concerning OAuth
to, but if the client wants to be really, really sure, it can
revoke all of its access tokens separately.
-- Justin
-Original Message-
From: Justin Richer [mailto:jric...@mitre.org]
Sent: Thursday, January 24, 2013 6:17 AM
To: Anthony Nadalin
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-ietf-oauth
simple and
straightforward and is exactly the same whether or not you're using the
revocation endpoint.
-- Justin
-Original Message-
From: Justin Richer [mailto:jric...@mitre.org]
Sent: Thursday, January 24, 2013 8:13 AM
To: Anthony Nadalin
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG
be cleaner and more RESTful API design. What do others
think?
-- Justin
On 01/22/2013 08:05 PM, Nat Sakimura wrote:
Action goes against REST principle.
I do not think it is a good idea.
=nat via iPhone
Jan 23, 2013 4:00、Justin Richer jric...@mitre.org のメッセージ:
(CC'ing the working group)
I'm
and logical endpoint options
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Justin Richer
Sent: Wednesday, January 23, 2013 7:47 AM
To: Nat Sakimura
Cc: Shiu Fun Poon; oauth@ietf.org
Subject: Re: [OAUTH-WG] Concerning OAuth introspection
:
Registration has to work in a multi-tenant environment so flexibility is
needed
-Original Message-
From: Justin Richer [mailto:jric...@mitre.org]
Sent: Wednesday, January 23, 2013 9:18 AM
To: Anthony Nadalin
Cc: Nat Sakimura; Shiu Fun Poon; oauth@ietf.org
Subject: Re: [OAUTH-WG
...@microsoft.com wrote:
Registration has to work in a multi-tenant environment so flexibility is
needed
-Original Message-
From: Justin Richer [mailto:jric...@mitre.org]
Sent: Wednesday, January 23, 2013 9:18 AM
To: Anthony Nadalin
Cc: Nat Sakimura; Shiu Fun Poon; oauth@ietf.org
and they are already stuck with the method that they have chosen, so they
need the flexability, to restrict this is nuts as people won't use it.
-Original Message-
From: Justin Richer [mailto:jric...@mitre.org]
Sent: Wednesday, January 23, 2013 9:27 AM
To: Anthony Nadalin
Cc: Nat Sakimura; Shiu
Paul B wrote one; maybe he open-sourced it?), it starts to become a lot
cheaper to support client registration on both sides of the interaction.
Eve
On 23 Jan 2013, at 8:34 AM, Sergey Beryozkin sberyoz...@gmail.com wrote:
On 23/01/13 15:47, Justin Richer wrote:
Which brings up
,
should audience be omitted? or be the same value as 'client_id'?
Thanks,
George
On 1/9/13 3:15 PM, Richer, Justin P. wrote:
On Jan 9, 2013, at 3:05 PM, Torsten Lodderstedt
tors...@lodderstedt.net mailto:tors...@lodderstedt.net wrote:
Hi Justin,
Am 09.01.2013 um 20:35 schrieb Justin Richer
Use cases that I was asked to collect are detailed here:
http://www.ietf.org/mail-archive/web/oauth/current/msg10407.html
-- Justin
On 01/10/2013 08:32 AM, Hannes Tschofenig wrote:
We will have our next OAuth conference call tomorrow at 1pm EST (for roughly
one hour).
John Nat kindly
is that the audience of the token is the entity for
which the token was minted which in the default OAuth2 case is the
client_id.
Any thoughts as to which is the best option? For now I'm going with
option 2.
Thanks,
George
On 1/10/13 9:18 AM, Justin Richer wrote:
In traditional OAuth, there really
value for it, I would remove it.
Igor
On 1/10/2013 11:59 AM, George Fletcher wrote:
That makes sense as well:)
Hopefully some others will chime in as I think this is an area that
could use some best practice guidelines.
Thanks,
George
On 1/10/13 11:53 AM, Justin Richer wrote:
I'm leaning
-introspection-01.txt
Date: Tue, 8 Jan 2013 14:48:47 -0800
From: internet-dra...@ietf.org
To: jric...@mitre.org
A new version of I-D, draft-richer-oauth-introspection-01.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.
Filename:draft-richer-oauth
the token
itself. This mechanism works just as well with an unstructured token as
input since the AS can store all of the token's metadata, like
expiration, separately and use the token's value as a lookup key.
-- Justin
Am 09.01.2013 um 20:10 schrieb Justin Richer jric...@mitre.org
I believe you're correct, Nov, and that this was potentially a mistake
from the RFC editor. That sentence *should* be talking about the
resource owner's password.
-- Justin
On 01/07/2013 06:53 AM, nov matake wrote:
Hi all,
I couldn't understand why their became the third party's in the
Access grant was the old term that Eran came up with, and it has been
replaced by authorization grant, which I agree is also not as well
defined as it could be. Both of these refer to the conceptual act of the
resource owner saying it is OK for this client to do these things. I
objected to the
Hi Adrian,
This isn't really an OAuth question, especially since OAuth is not an
authentication protocol on its own. It is used by several authentication
protocols, such as OpenID Connect, Google, and Facebook -- which is
where your questions really lie. Thus, OAuth itself can't help you with
I'd like to present two use cases for signed tokens, for input into the
ongoing MAC/HoK/higher-security discussion. Both of these are actual
cases that I've done in the past, and we've used either OAuth 1 or JW*
to solve them. I think that with the right tooling, a MAC-token-like
thing could
Sounds reasonable to me.
-- Justin
On 12/25/2012 08:19 AM, Torsten Lodderstedt wrote:
Hi Peter,
your proposal sounds reasonable.
Since it involves a change to the interface spec (400 instead of 403
in case of unauthorized access) I would like to ask the working group
for feedback.
What
I'm fine with this approach, though I'd leave in a RECOMMEND for the
refresh token - access token cascading delete, since it will be a
common one.
-- Justin
On 12/26/2012 11:14 AM, Torsten Lodderstedt wrote:
Hi John,
thanks for your feedback.
After having thought through this topic again
I would be fine with a machine-readable instance_id parameter to be
paired with the human-readable items that are in there today. However,
since this is a value that goes to the Authorization Endpoint and
therefore goes through the browser, it MUST always be treated as
self-asserted by the
601 - 700 of 888 matches
Mail list logo
