Re: [OAUTH-WG] A question on token revocation.

On Thu, Feb 7, 2013 at 12:49 PM, wrote: > > I guess RO could initiate access token revocation for a client by > including authorization code in the request to AS. > Comments? That creates a dependency on the grant type. Thanks & regards, -Prabath > > > > > oauth-boun...@ietf.org 写于 2013-02-0

Re: [OAUTH-WG] A question on token revocation.

I guess RO could initiate access token revocation for a client by including authorization code in the request to AS. Comments? oauth-boun...@ietf.org 写于 2013-02-07 02:32:28: > Hi Torsten, > > Thanks for your feedback.. I will submit a draft... > > Thanks & regards, > -Prabath > On Wed, Feb

Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-02.txt

Hi Justin, I believe this is addressing one of the key missing part in OAuth 2.0... One question - I guess this was discussed already... In the spec - in the introspection response it has the attribute "valid" - this is basically the validity of the token provided in the request. Validation cri

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-05.txt

Hi Justin, Thanks for working to make progress on the OAuth Registration draft. Reading through the changes, it seems to me that a number of changes were made that there wasn't yet working consensus for - in fact, some of which I don't recall being discussed by the working group at all. These

Re: [OAUTH-WG] Why OAuth it self is not an authentication framework ?

Lewis, Specifically, we have defined the following to the id_token. issREQUIRED. Issuer Identifier for the Issuer of the response.subREQUIRED. Subject identifier. A locally unique and never reassigned identifier within the Issuer for the End-User, which is intended to be consumed by the Client. e

Re: [OAUTH-WG] I'm concerned about how the sniffability of oauth2 requests

On 06/02/13 17:56, William Mills wrote: Yes, MAC relies on SSL for transport security. But you have bigger problems than that if SSL is broken, because your primary authentication credential is compromised now. +1 Do we need to address sslstrip here if it's a general attack on SSL transport fo

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-05.txt

Thanks to all of the discussion over the last few weeks and some key input from Nat Sakimura, Eve Maler, and others, I've put out a revision of the DynReg specification that is a major change from recent revisions, but actually brings it back closer to the original -01 draft. The "operation" pa

[OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-05.txt

A New 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

[OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-02.txt

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 claims - clarified what happens if the authentication is bad -- Justin

Re: [OAUTH-WG] A question on token revocation.

Hi Torsten, Thanks for your feedback.. I will submit a draft... Thanks & regards, -Prabath On Wed, Feb 6, 2013 at 11:55 PM, Torsten Lodderstedt < tors...@lodderstedt.net> wrote: > Hi Prabath, > > we tried to address both use cases in the first revisions of the draft. > The API was well suited f

Re: [OAUTH-WG] A question on token revocation.

Hi Prabath, we tried to address both use cases in the first revisions of the draft. The API was well suited for client-driven revocation but not the resource owner - driven use case. There are definitely differences with respect to the protocol design, at least regarding authentication and auth

Re: [OAUTH-WG] I'm concerned about how the sniffability of oauth2 requests

On Wed, Feb 6, 2013 at 11:26 PM, William Mills wrote: > Yes, MAC relies on SSL for transport security. But you have bigger > problems than that if SSL is broken, because your primary authentication > credential is compromised now. > +1 > > Do we need to address sslstrip here if it's a general

Re: [OAUTH-WG] I'm concerned about how the sniffability of oauth2 requests

Yes, MAC relies on SSL for transport security.  But you have bigger problems than that if SSL is broken, because your primary authentication credential is compromised now. Do we need to address sslstrip here if it's a general attack on SSL transport for the browser? __

Re: [OAUTH-WG] I'm concerned about how the sniffability of oauth2 requests

On Mon, Feb 4, 2013 at 9:57 PM, William Mills wrote: > There are two efforts at signed token types: MAC which is still a > possibility if we wake up and do it, and the "Holder Of Key" type tokens. > If someone can use sslstrip then even MAC is not safe - since MAC key needs to be transferred over

Re: [OAUTH-WG] Why OAuth it self is not an authentication framework ?

Adam, We have made some changes in the latest draft to address some input from Google that I think may also address your need to using the id_token in an assertion or possibly as an access token to a federated RS. I can go over it with you if you like. John B. On 2013-02-06, at 9:05 AM, Lewis

Re: [OAUTH-WG] Why OAuth it self is not an authentication framework ?

Hi Bill, My reason for using OAuth rather than OIDC is because the id_token in OIDC is audience restricted to the client. This was clearly intended for WebSSO / authentication to a client running on a web server. It does not help the case where the user of a RESTful native client want to auth

Re: [OAUTH-WG] A question on token revocation.

On Wed, Feb 6, 2013 at 9:04 PM, Todd W Lainhart wrote: > > Resource owner needs to know the consumer key (represents the OAuth > Client app) & scope to revoke the access token for a given client. > > I see - you're saying that requiring client credentials on the end point > is the problem? > In

Re: [OAUTH-WG] A question on token revocation.

Sure that can done.. Do you see any issues having discuss that under the same spec.. The purpose of both are the same. Only the actor differs. Thanks & regards, -Prabath On Wed, Feb 6, 2013 at 9:00 PM, Todd W Lainhart wrote: > > If you would like to see the RO-initiated token revocation go thro

Re: [OAUTH-WG] A question on token revocation.

> Resource owner needs to know the consumer key (represents the OAuth Client app) & scope to revoke the access token for a given client. I see - you're saying that requiring client credentials on the end point is the problem? Todd Lainhart Rational software IBM Corporation 550 King Street,

Re: [OAUTH-WG] A question on token revocation.

On Wed, Feb 6, 2013 at 8:49 PM, Justin Richer wrote: > > On 02/06/2013 10:13 AM, Prabath Siriwardena wrote: > > > > On Wed, Feb 6, 2013 at 8:19 PM, Justin Richer wrote: > >> These are generally handled through a user interface where the RO is >> authenticated directly to the AS, and there's not

Re: [OAUTH-WG] A question on token revocation.

> If you would like to see the RO-initiated token revocation go through (not grant revocation, mind you -- that's related, but different), then I would suggest that you start specifying exactly how that works. +1 Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA

Re: [OAUTH-WG] How soon until last call on introspection and revocation

I think that there are still fundamental design disagreements that would need to be resolved. Sent from Windows Mail From: Justin Richer Sent: ‎February‎ ‎6‎, ‎2013 ‎6‎:‎57‎ ‎AM To: Hannes Tschofenig CC: IETF oauth WG Subject: Re: [OAUTH-WG] How soon until last call on introspection and revocati

Re: [OAUTH-WG] A question on token revocation.

On 02/06/2013 10:13 AM, Prabath Siriwardena wrote: On Wed, Feb 6, 2013 at 8:19 PM, Justin Richer > wrote: 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" he

Re: [OAUTH-WG] A question on token revocation.

+1 From: Prabath Siriwardena To: Todd W Lainhart Cc: "oauth@ietf.org WG" ; oauth-boun...@ietf.org Sent: Wednesday, February 6, 2013 7:04 AM Subject: Re: [OAUTH-WG] A question on token revocation. On Wed, Feb 6, 2013 at 7:51 PM, Todd W Lainhart wrote:

Re: [OAUTH-WG] A question on token revocation.

On Wed, Feb 6, 2013 at 8:19 PM, Justin Richer wrote: > 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. > Why do you think leaving access token revocation by RO to a proprieta

Re: [OAUTH-WG] How soon until last call on introspection and revocation

>That said, it doesn't mean we can't all just *work* on it... Agreed. Thanks for the clarification. Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com From: Justin Richer To: Hannes Tschofen

Re: [OAUTH-WG] A question on token revocation.

On Wed, Feb 6, 2013 at 7:51 PM, Todd W Lainhart wrote: > > There can be cases where resource owner needs to revoke an authorized > access token from a given client. > > Why wouldn't the RO go through the client to revoke the token? > RO needs not to go through the client to revoke. Resource owne

Re: [OAUTH-WG] How soon until last call on introspection and revocation

Thanks Hannes. > That document is not even a working group item. Ha. I hadn't noticed that - I now see it is part associated to the "Network Working Group" instead of "OAuth Working Group". I'm confused, and perhaps it's just IETF ignorance, or me not paying attention. What does it mean fo

Re: [OAUTH-WG] How soon until last call on introspection and revocation

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. T

Re: [OAUTH-WG] A question on token revocation.

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 pro

Re: [OAUTH-WG] How soon until last call on introspection and revocation

Hi Todd, two answers: 1) Token Revocation: I had initiated a Working Group Last Call for the token revocation document end of November: http://www.ietf.org/mail-archive/web/oauth/current/msg10102.html As you have seen on the list, this has generated a fair amount of discussion. I hope that

[OAUTH-WG] How soon until last call on introspection and revocation

Does anyone have any intuition as to how far away we are on last call for introspection and revocation? Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com ___

Re: [OAUTH-WG] A question on token revocation.

> There can be cases where resource owner needs to revoke an authorized access token from a given client. Why wouldn't the RO go through the client to revoke the token? Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L)

[OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 4th February 2013

Here are my notes. Participants: * John Bradley * Derek Atkins * Phil Hunt * Prateek Mishra * George Fletcher * Bill Mills * Hannes Tschofenig Notes: We discussed the slides available at http://www.tschofenig.priv.at/OAuth2-Security-4Feb2013.ppt, which contained a summary of the earlier dis

[OAUTH-WG] A question on token revocation.

I am sorry if this was already discussed in this list.. Looking at [1] it only talks about revoking the access token from the client. How about the resource owner..? There can be cases where resource owner needs to revoke an authorized access token from a given client. Or revoke an scope.. How