Re: [OAUTH-WG] Limiting signed requests to use the Authorization request header

Another use case is where a rich client wants to bootstrap a web session with the same identity (rich client to web SSO). Assuming that the web session will be established via OAuth with signatures, there is no way to fire up the browser with a signed URL if the OAuth parameters and signature

Re: [OAUTH-WG] Limiting signed requests to use the Authorization request header

with a protected resource request? That seems odd. Not odd at all a lot of the Eclipse applications can work this way *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf Of *Eran Hammer-Lahav *Sent:* Thursday, April 08, 2010 7:41 AM *To:* George Fletcher

Re: [OAUTH-WG] modifying the scope of an access token

I'm definitely interesting in the ability to change the scope dynamically, replacing an existing access token with a new access token. We use something very similar today in the AOL service APIs. One question in regards to your proposal. If the client asks for a scope that the user hasn't

Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 2

without HTTPS. We'd rather increase security by deploying HTTPS rather than requiring developers to sign their requests. Thanks Allen On 5/27/10 11:11 AM, George Fletcher gffle...@aol.com wrote: Hmm... to me this says... Yahoo won't deploy PRs that require client_secret signatures

Re: [OAUTH-WG] Definition of XML response format

I don't know if this is helpful or not... but there was a proposed extension for OAuth 1.0 dealing with encoding OAuth responses in different body formats... this can be found on the now extinct oauth-extensions google group.

Re: [OAUTH-WG] Partially standardized format for access tokens?

On 6/4/10 9:53 AM, Luke Shepard wrote: Having a single resource server that works with multiple independent auth servers is not in scope for OAuth. That said, there's nothing to stop multiple servers to agree amongst themselves to have a standardized format for access token- and if necessary,

Re: [OAUTH-WG] Partially standardized format for access tokens?

On 6/8/10 9:58 AM, Luke Shepard wrote: Again: can you provide a specific, real-world example where this is necessary? I'd rather not deal in hypotheticals. I've already answered the case of a hypothetical endpoint that accepts both SAML and JSON-encoded tokens. I believe one such case is

Re: [OAUTH-WG] Partially standardized format for access tokens?

Here is where I see the differences... #2 forces person B to go through an authentication event at photos.example.com while #3 allows the client person B is using to get the access token at time of authentication to the client. So, for #2 person B will likely have to do 2 authentication

Re: [OAUTH-WG] User-agent flow and pre-registered redirect_uri

Makes perfect sense as we have the same model for our clients tokens:) The one use case we've encountered is that this model revokes the tokens for all clients with the same client_id. So if I've got three of the same client installed (on three computers) and they likely all have the same

Re: [OAUTH-WG] User-agent flow and pre-registered redirect_uri

that Google used with OAuth1 since we're not requiring the client secret for signing anymore. Thoughts? -- Justin On Fri, 2010-06-11 at 10:38 -0400, George Fletcher wrote: Makes perfect sense as we have the same model for our clients tokens:) The one use case we've encountered

Re: [OAUTH-WG] User-agent flow and pre-registered redirect_uri

On 6/11/10 12:34 PM, Marius Scurtescu wrote: On Fri, Jun 11, 2010 at 9:25 AM, George Fletchergffle...@aol.com wrote: On 6/11/10 12:07 PM, Marius Scurtescu wrote: On Fri, Jun 11, 2010 at 8:59 AM, David Recordonrecord...@gmail.com wrote: That sounds like a security

Re: [OAUTH-WG] User-agent flow and pre-registered redirect_uri

On 6/11/10 2:09 PM, Marius Scurtescu wrote: On Fri, Jun 11, 2010 at 10:07 AM, George Fletchergffle...@aol.com wrote: On 6/11/10 12:34 PM, Marius Scurtescu wrote: On Fri, Jun 11, 2010 at 9:25 AM, George Fletchergffle...@aol.comwrote: On 6/11/10 12:07 PM, Marius

Re: [OAUTH-WG] Fwd: Re: in-app logout?

+1 to re-delegation I'd like to add that with down-scoping and re-delegation it would be nice to be able to bind a re-delegated access token to the client that will present it. With re-delegation, the down-stream client doesn't have an easy refresh token so a short-lived access token might

Re: [OAUTH-WG] User-agent flow and pre-registered redirect_uri

On 6/11/10 3:15 PM, Marius Scurtescu wrote: On Fri, Jun 11, 2010 at 11:46 AM, George Fletchergffle...@aol.com wrote: On 6/11/10 2:09 PM, Marius Scurtescu wrote: On Fri, Jun 11, 2010 at 10:07 AM, George Fletchergffle...@aol.com wrote: Well... given this is a POST and

Re: [OAUTH-WG] proposal for signatures

The only additional value might be during key rotation. If key_id is removed, then both (or n) have to be checked. Probably not a huge issue. Thanks, George On 6/22/10 4:45 PM, David Recordon wrote: Hey Dick, in answering my questions you made my point. If keys are managed out of band -- as

Re: [OAUTH-WG] Device profile draft

Looks good. Are there any restrictions on the device_code such that it has to be under a certain size? Seems like it would be good to protect against random polling attacks (I presume this is what the Google research refers to). If there are no size restrictions then the device_code could be

Re: [OAUTH-WG] Returning HTTP 200 on Error for JSONP

I believe Flash (in the browser) has similar constraints. Don't know about Silverlight. Thanks, George On 8/17/10 10:33 PM, John Panzer wrote: Is there any legit reason other than jsonp specifically? In the wild I mean. On Tuesday, August 17, 2010, Brian Eatonbea...@google.com wrote: On

Re: [OAUTH-WG] Basic signature support in the core specification

+1 I am agnostic as to whether this means we define the signatures within the spec or just reference/profile some other work. The fewer number of signature algorithms we have to implement the better:) George On 9/23/10 9:43 PM, Eran Hammer-Lahav wrote: Since much of this recent debate was

Re: [OAUTH-WG] Signatures...what are we trying to solve?

I think of the signature issues as falling into two classes... I think they map to your classification as well... * *Signing tokens* is important for interoperability especially looking forward to a time when tokens issued by multiple Authorization Servers are accepted at a given

Re: [OAUTH-WG] Looking for a compromise on signatures and other open issues

+1 I think this is a great path forward On 9/28/10 2:25 AM, Eran Hammer-Lahav wrote: (Please take a break from the other threads and read this with an open mind. I have tried to make this both informative and balanced.) --- IETF Process For those unfamiliar with the IETF process, we

Re: [OAUTH-WG] Signatures...what are we trying to solve?

*From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf Of *George Fletcher *Sent:* Tuesday, September 28, 2010 11:39 AM *To:* OAuth WG *Subject:* Re: [OAUTH-WG] Signatures...what are we trying to solve? I think

Re: [OAUTH-WG] Signatures...what are we trying to solve?

*From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf Of *George Fletcher *Sent:* Tuesday, September 28, 2010 11:39 AM *To:* OAuth WG *Subject:* Re: [OAUTH-WG] Signatures...what are we trying to solve? I think of the signature issues as falling

Re: [OAUTH-WG] So back to use cases? (was RE: Call for Consensus on Document Split)

I'm not sure what you mean by signatures improving privacy? I don't see signature having much effect on privacy. Encryption is needed for that. However, signatures do limit the scope of exposure should a token get exposed in some manner. In that sense a user is protected because a leaked

Re: [OAUTH-WG] VOTE: Token type response parameter

+1 for #3 for me as well On 11/18/10 10:27 AM, William Mills wrote: #3. It's clear and well defined. No chance of confusion. 1. Missing type response parameter means bearer token 2. Missing type response parameter means whatever the service default token type is 3. Servers must include an

Re: [OAUTH-WG] OAuth Bearer Token draft

I'm not crazy about the compromise either, but it's not possible for a site using JSONP and it's cross-domain tricks to set the Authorization header out of the browser or POST the data out of the browser in a cross-domain way (due to the same origin browser policy). Quoting Eran from a

Re: [OAUTH-WG] OAuth Bearer Token draft

+1 On 3/11/11 2:56 AM, tors...@lodderstedt.net wrote: Why not bearer_token? This would be in line with the Authorization scheme name. regards, Torsten. Gesendet mit BlackBerry® Webmail von Telekom Deutschland -Original Message- From: Mike Jonesmichael.jo...@microsoft.com Sender:

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

Along this same line... To make sure I understand, the attacker must execute a MITM attack against the redirect_uri so that it receives the code value and ensures the code value is never exchanged at the authorization service by the original requester. Then the attacker takes the code and

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

Hi Francisco, So the examples that Justin gave were either localhost or non HTTP based schemes. If OAuth2 is to support these other schemes (often used in mobile clients) then I'm not sure how TLS can be a MUST unless it's qualified to apply to HTTP based URLs only. Is it sufficient to

Re: [OAUTH-WG] bearer token authorization header

Do I understand this correctly that each resource owner can define it's own format for the printable non-whitespace ASCII characters? It seems like that would make it difficult for clients to use standard libraries because the Authorization header format could be different on a per

Re: [OAUTH-WG] bearer token authorization header

and the Resource Server still need to agree upon the semantics of the bearer token exchanged. -- Mike -Original Message- From: John Kemp [mailto:j...@jkemp.net] Sent: Wednesday, May 25, 2011 10:11 AM To: Mike Jones Cc: Marius Scurtescu; George Fletcher; OAuth WG Subject: Re: [OAUTH-WG

Re: [OAUTH-WG] consistency of token param name in bearer token type

Brief pointer to the history of this change. This change was adopted in draft 4 of the bearer spec as there were concerns with the previous parameter name of 'oauth_token'. The suggestion was made to use 'bearer_token' so that it matches the scheme used in the Authorization header. The

Re: [OAUTH-WG] consistency of token param name in bearer token type

? - John On Jun 10, 2011, at 2:58 PM, George Fletcher wrote: Yes, that's fine with me. Thanks, George On 6/10/11 4:20 AM, David Recordon wrote: George, Doug and Eran are you alright with the Bearer token spec using the parameter name access_token as well? On Wed, Jun 8, 2011 at 4:50 PM, Marius

Re: [OAUTH-WG] consistency of token param name in bearer token type

+1 :) On 6/10/11 9:23 AM, Doug Tangren wrote: I hope hope that if it changes again this time, it doesn't change again :)! ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Resource Owner Password Credentials question/feedback

I'm working on spec'ing out a use of the Resource Owner Password Credentials flow and in trying to map out possible error cases, realized that there is no good error for the case that the resource owner's password credentials are invalid. Section 4.3 of draft 16 references section 5.2 for

Re: [OAUTH-WG] Example tokens

+1 If the system just needs a random identifier with state maintained on the server, then the current tokens are fine. For those systems that plan to encrypt data in the scopes (or use JWTs) they will be much larger. Thanks, George On 7/7/11 9:24 AM, William J. Mills wrote: Access tokens

Re: [OAUTH-WG] Rechartering JSON based request.

The main reason to include the OAuth parameters in the request is to ensure that the request object was not modified in transit since the JSON request object can be signed. Agreed that it would be simpler if OAuth adopted the JSON request style. Thanks, George On 10/27/11 1:33 PM,

Re: [OAUTH-WG] OAuth 2.0 and Access Control Lists (ACL)

I would also recommend looking at User-Managed-Access which provides this kind of layer on top of OAuth2. http://kantarainitiative.org/confluence/display/uma/UMA+Explained Thanks, George On 12/18/11 12:05 PM, Melvin Carvalho wrote: Quick question. I was wondering if OAuth 2.0 can work with

Re: [OAUTH-WG] Native clients 'confidentiality'

Hi Paul, Is the need to authenticate the client a need to ensure that the content is only displayed on certain devices/clients? Or prevent phishing/stealing of authz bearer tokens? As you point out, it's possible to protect the bearer tokens and associated refresh tokens via other

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011

The problem is that even if the Authorization Server only gives out credentials to trusted clients, those clients can be hacked and the credentials compromised allowing for impersonation of the trusted client. Obviously, protecting the credentials is easier if the client is a web server with

Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer

+1 On 3/11/12 12:45 PM, Richer, Justin P. wrote: +1 *From:* oauth-boun...@ietf.org [oauth-boun...@ietf.org] on behalf of Brian Campbell [bcampb...@pingidentity.com] *Sent:* Sunday, March 11, 2012 9:50 AM *To:* John

Re: [OAUTH-WG] OAuth WG Re-Chartering

+1 to JWT and AS-RS communication over dynamic registration On 3/21/12 3:52 PM, John Bradley wrote: I don't think dynamic registration completely removes the need for a public client, that can't keep secrets. While we did do dynamic client registration for Connect that is a more constrained

Re: [OAUTH-WG] OAuth WG Re-Chartering

-AS first and consider client registration a major missing piece. Why? Because otherwise clients cannot dynamically bind to any OAuth-AS at runtime but have to pre-register (with any?) :-(. regards, Torsten. Am 21.03.2012 21:50, schrieb George Fletcher: +1 to JWT and AS-RS communication over

Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)

And the AOL is working as well (though it was down for a bit:) On 4/19/12 12:15 PM, Christian Weiske wrote: Hello Dick, Gmail, aol, and yahoo all put up webfinger endpoints, but there hasn't been much movement, I think due to the chicken and egg nature of adoption around decentralized tools.

Re: [OAUTH-WG] Inter-domain AS/RS communication (revisited)

I'm not sure why the dependency on the unstructured token. You can have a small structured token which provides some additional capabilities. That said, as long as the RS can determine which AS the token came from, this solutions works well. I believe a few other implementations use a

Re: [OAUTH-WG] Inter-domain AS/RS communication (revisited)

If you are using the userinfo endpoint concept to verify the unstructured token with the appropriate AS, then all you really need from the unstructured token is which AS to send it to. If your problem space is constrained so that this is straight forward, then there isn't a significant reason

Re: [OAUTH-WG] Clarification in Section 2.0 of draft-ietf-oauth-revocation-00

Paul, I think I came to a different conclusion... If I use the Resource Owner Password Credential flow and get back both an access_token and a refresh_token then I would assume that the issued access_token is tied in some way to the refresh_token. If the refresh_token is revoked, then my

Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

I agree that there is value in allowing the client_id to be a URI. The problem is that the ':' of the URI is not allowed in HTTP Basic which is required by the OAuth2 spec for client authentication. We could encode the client_id before HTTP Basic but that needs to be documented and adds

Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

+1 We've supported #3 for quite some time in our public APIs that pre-date OAuth. Thanks, George On 8/9/12 3:37 PM, Justin Richer wrote: Use case #2: signature protection over plain HTTP parameters MAC gives us message-level signing in a way that doesn't require all the parameters to be

Re: [OAUTH-WG] Dynamic registration of client application instances

I think it's an interesting idea... I'm just not sure how to tie the dynamic client registration to a verified user email address. To get a verified email address, most OAuth2 flows require the client_id to be already provisioned. I do agree that from the AS/OP perspective, we don't want to

Re: [OAUTH-WG] need advice on sign out after performing sign in via OAuth 10x

There is no standardization of the logout flow in OAuth or OpenID (there is in OpenID Connect as John mentioned) so your option 3... 3) The third option : displaying some informative text when the user sings out from the application informing him that he/she signed out from our

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt

argue it would be more robust to leave both specs separated. What do others think? regards, Torsten. Am 07.01.2013 17:12, schrieb George Fletcher: One quick comment... Section 2.0: Both RFC 6750 and this specification define the 'invalid_token' error code. Should this spec reference

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt

, schrieb George Fletcher: My concern with leaving both specs separated is that over time the semantics of the two error codes could diverge and that would be confusing for developers. If we don't want to create a dependency on RFC 6750, then I would recommend a change to the error code name so

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt

eter value Perhaps we should drop the error-code and use invalid-request with a error-description explaining the token parameter is not usable. Regards Peter On 09.01.2013 14:08, George Fletcher wrote: Hi Peter,

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

I had the same confusion about what is 'audience' in OAuth? today working on a completely different project. I think for the default OAuth2 deployment, scopes take the place of audience because the scopes identify the authorization grant(s) at the resource servers affiliated with the

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

PR and you need to keep things straight in a large backend. So while I agree it'd be better if OAuth had an 'audience' concept all the way through, I don't think it should be precluded from the introspection response just because it doesn't. -- Justin On 01/09/2013 04:47 PM, George

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

audience. -- Justin On 01/10/2013 11:52 AM, George Fletcher wrote: So in the default case I see two options for an AS that wants to implement this endpoint... 1. Omit 'audience' from the response: The rationale here is that there really isn't an explicit audience and what clients need

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

Additional feedback on the introspection endpoint. What is the expected error response if the introspection endpoint is using client credentials as recommended in section 2.1 The endpoint SHOULD also require some form of authentication to access this endpoint, such as the Client

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

to describe it. There was some confusion about the {valid: false} response as well, so now I'm thinking that should be pulled into an Errors section, perhaps? -- Justin On Jan 11, 2013, at 12:38 PM, George Fletcher gffle...@aol.com mailto:gffle...@aol.com wrote: Additional feedback

Re: [OAUTH-WG] draft-ietf-oauth-revocation-04

First, just want to say this is a great write up of the situation. Thanks! A couple of additional thoughts regarding token management and processing... 1. If all tokens being revoked are tokens issued by the same Authorization Server (AS) then it can easily mark which are refresh and which

Re: [OAUTH-WG] draft-ietf-oauth-revocation

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 (as suggested by Peter and George). I don't see the need to register it (see

Re: [OAUTH-WG] draft-ietf-oauth-revocation

P. jric...@mitre.org mailto:jric...@mitre.org To: George Fletcher gffle...@aol.com mailto:gffle...@aol.com, Cc: OAuth WG oauth@ietf.org mailto:oauth@ietf.org Date: 02/04/2013 04:10 PM Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation Sent by: oauth-boun...@ietf.org mailto:oauth-boun...@ietf.org

Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names

As a simplifying option... why not just require human-readable fields to require a script-tag. This way it is always explicit what language/locale the text is for. It then becomes the responsibility of the AS to return an appropriate response if there is not a direct match between a request

Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt

I still argue that the initial client access token (not assertion) is really just an authorization token for the endpoint (like any other OAuth2 protected resource). There is nothing within OAuth2 that precludes a system using structured authorization tokens that contain claims and using that

Re: [OAUTH-WG] Client Instances of An Application - Was: Re: Last call review of draft-ietf-oauth-dyn-reg-10

+1 for leaving dyn reg as is and working on a profile that enables this more domain specific scenario. I agree with Phil and Justine that it's important... I just don't think it should be put in the core dyn reg spec. Thanks, George On 6/4/13 12:45 PM, Justin Richer wrote: I agree with the

Re: [OAUTH-WG] Client Instances of An Application - Was: Re: Last call review of draft-ietf-oauth-dyn-reg-10

Argh! Typos (due to iPhone? no bad brain - hand connections). Sorry Justin! On 6/4/13 1:56 PM, George Fletcher wrote: +1 for leaving dyn reg as is and working on a profile that enables this more domain specific scenario. I agree with Phil and Justine that it's important... I just don't think

Re: [OAUTH-WG] OX needs Dynamic Registration: please don't remove!

to support, monitor and report on #2 yes, 1 physical endpoint acting as multiple authorization servers *From:*George Fletcher [mailto:gffle...@aol.com] *Sent:* Tuesday, August 13, 2013 7:40 AM *To:* Anthony Nadalin *Cc:* m...@gluu.org; Justin Richer; oauth@ietf.org *Subject:* Re: [OAUTH-WG] OX needs

Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- George Fletcher http://connect.me/gffletch ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth Token Introspection as an OAuth Working Group Item

We also have a use case where the AS is provided by a partner and the RS is provided by AOL. Being able to have a standardized way of validating and getting data about the token from the AS would make our implementation much simpler as we can use the same mechanism for all Authorization

Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth Token Introspection as an OAuth Working Group Item

(and simplify) a majority of cases._ Phil @independentid www.independentid.com http://www.independentid.com phil.h...@oracle.com mailto:phil.h...@oracle.com On Jul 29, 2014, at 3:24 PM, George Fletcher gffle...@aol.com mailto:gffle...@aol.com wrote: We also have a use case where

Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth Token Introspection as an OAuth Working Group Item

Phil’s comment that it would be good to understand the use cases that this is intended to solve before embarking on a particular solution path. -- Mike *From:*OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *George Fletcher *Sent:* Tuesday, July 29, 2014 3:25 PM *To:* Phil Hunt; Thomas

Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth Token Introspection as an OAuth Working Group Item

Of *George Fletcher *Sent:* Tuesday, July 29, 2014 3:25 PM *To:* Phil Hunt; Thomas Broyer *Cc:* oauth@ietf.org *Subject:* Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth Token Introspection as an OAuth Working Group Item We also have a use case where the AS is provided by a partner

Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth Symmetric Proof of Posession for Code Extension as an OAuth Working Group Item

Yes, I support add this as a WG work item. On 7/28/14, 1:33 PM, Hannes Tschofenig wrote: Hi all, during the IETF #90 OAuth WG meeting, there was strong consensus in adopting the OAuth Symmetric Proof of Posession for Code Extension (draft-sakimura-oauth-tcse-03.txt) specification as an OAuth

Re: [OAUTH-WG] Confirmation: Call for Adoption of Request by JWS ver.1.0 for OAuth 2.0 as an OAuth Working Group Item

Hannes Derek ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- George Fletcher http://connect.me/gffletch ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman

Re: [OAUTH-WG] RS as a client guidance

Hi Adam, If all the RS needs is say the sub field for the user, then you might want to look at the introspection spec as this allows the AS/OP to determine if the RS is authorized to introspect the token. I know that Justin implemented a simple token exchange model that allowed for

[OAUTH-WG] OAuth2 2 legged flows with JWT client assertions

Hi, I just want to verify my reading of RFC 7523[1] for the use case where a client wants to get an access token for itself to use as authorization for future API calls. This is effectively exchanging a JWS for a "short lived" access token. My understanding of section 2.2 of RFC 7523, is

Re: [OAUTH-WG] OAuth2 2 legged flows with JWT client assertions

for a new token, then that’s a case of using the JWS as an assertion directly to the AS and getting a token there. But I agree that it’s confusing that there are two similar mechanisms here. — Justin On Sep 15, 2015, at 2:09 PM, George Fletcher <gffle...@aol.com &

Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation

uration of the ASes issuer/endpoint information anyhow and they just need to confirm that the issuer value received in the authorization response is the same issuer as that the request was sent to. Hans. On 1/11/16 1:14 PM, Mike Jones wrote: Correct *From:*George Fletcher [mailto:gffle...@aol

Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation

Thanks Mike. One question after reading about the different attack vectors and this spec... How are the 'iss' and 'aud' values returned with the 'code' and 'state' parameters. It seems the client needs to verify the endpoints before making the request to exchange the code for a token. If the

Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation

a bunch, -- Mike *From:*George Fletcher [mailto:gffle...@aol.com] *Sent:* Monday, January 11, 2016 10:21 AM *To:* Mike Jones <michael.jo...@microsoft.com>; oauth@ietf.org *Subject:* Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation Thanks Mike. One question after reading about the different

Re: [OAUTH-WG] OAuth 2.0 for Native Apps: Call for Adoption Finalized

+1 On 2/5/16 10:10 AM, Adam Lewis wrote: +1 that it should be Informational. Also, I never got to respond to the original request, but I am heavily in favor of this draft. I talk with a lot of native app developers who are clueless about how to implement OAuth. The core RFC is very web app

Re: [OAUTH-WG] Call for Adoption

I agree that in many cases the RS and AS are in different domains and I think that OAuth2 explicitly was designed to support that. I don't see how "sending a token to a bad RS" is a variant of the mix-up attack. To me, it's the clients responsibility to send the token to an appropriate

Re: [OAUTH-WG] Can the repeated authorization of scopes be avoided ?

ot; process could obtain a new client_id for that instance. Cookies might work, or have the app generate a unique identifier and use that in conjunction with the client_id? Thanks, George On 1/27/16 11:07 AM, Thomas Broyer wrote: On Wed, Jan 27, 2016 at 1:54 PM George Fletcher <gffle..

Re: [OAUTH-WG] Can the repeated authorization of scopes be avoided ?

My recommendation, like the others, is to store consent by client_id:user and then try and leverage dynamic client registration if instance level consent is needed. On 1/27/16 11:43 AM, George Fletcher wrote: Yes, I was thinking mostly of "native apps"... though you bring up a

Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption

We still have a problem with AT leaking. I think that needs to be dealt with separately. Access tokens should have a audience (by value or by introspection) the client needs to tell the AS what resource it want s to use the token at and have that included as the audience or the request

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

+1 for “OAuth 2.0 Authorization Server Discovery” On 2/25/16 2:10 PM, Mike Jones wrote: Thanks for your thoughts, Vladimir. I’m increasingly inclined to accept your suggestion to change the title from “OAuth 2.0 Discovery” to “OAuth 2.0 Authorization Server Discovery”. While the abstract

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

e current experience, and OAuth does allow the token response JSON object to be extended with additional members (as it's done in OpenID Connect already). Cheers, Vladimir -- James Manger From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of George Fletcher Sent: Thursday, 25 February 2

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

to be protected is a token from being used where it shouldn't be (which is solved by Pop) Thanks, George On 2/25/16 10:25 AM, George Fletcher wrote: Interesting... this is not at all my current experience:) If a RS goes from v2 of it's API to v3 and that RS uses the current standard

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

der. A better approach would be including a list of web origins in the token response beside the access_token field. -- James Manger *From:*OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *George Fletcher *Sent:* Thursday, 25 February 2016 6:17 AM *To:* Phil Hunt <phil.h...@oracle.com

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

tf.org <mailto:oauth-boun...@ietf.org>] *On Behalf Of *George Fletcher *Sent:* Friday, 26 February 2016 2:28 AM *To:* Vladimir Dzhuvinov <vladi...@connect2id.com <mailto:vladi...@connect2id.com>>; oauth@ietf.org <mailto:oauth@ietf.org> *Subject

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture. What if a RS moves to a new endpoint? All clients would be required to get new tokens (if I understand correctly). And the RS move would have to

Re: [OAUTH-WG] best practice for Native app + state param?

+1 to both using state and PKCE (especially when using system web controllers; e.g. safari-view-controller). On 1/19/16 11:29 AM, Justin Richer wrote: I think there’s no advice because it’s not different: you should still be using the state parameter. Just use a random value with high enough

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

+1 for adoption On 1/21/16 2:53 AM, Roland Hedberg wrote: +1 for adoption 21 jan 2016 kl. 07:14 skrev Antonio Sanso : +1 for adoption On Jan 19, 2016, at 12:49 PM, Hannes Tschofenig wrote: Hi all, this is the call for adoption of OAuth 2.0

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Security: OAuth Open Redirector

+1 On 1/21/16 12:34 PM, Brian Campbell wrote: +1 On Thu, Jan 21, 2016 at 7:48 AM, John Bradley > wrote: Yes we did discuss changing the title as part of adopting it. On Jan 21, 2016, at 11:28 AM, Nat Sakimura

Re: [OAUTH-WG] Call for adoption: OAuth 2.0 for Native Apps

I'm also +1 for adoption On 1/21/16 2:56 AM, Roland Hedberg wrote: +1 for adoption 21 jan 2016 kl. 07:11 skrev William Denniss : I believe this is important work. The original OAuth 2 spec left the topic of native apps largely undefined which is fair enough, the

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Device Flow

+1 for adoption On 1/19/16 6:48 AM, Hannes Tschofenig wrote: Hi all, this is the call for adoption of OAuth 2.0 Device Flow, see https://tools.ietf.org/html/draft-denniss-oauth-device-flow-00 Please let us know by Feb 2nd whether you accept / object to the adoption of this document as a

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

I'm still catching up... but to this point specifically... Doesn't this require that the same client_id NOT be used simultaneously at two (or more) Authorization Servers? If so, I don't believe that is a viable option. It's a little late in the game to be putting requirements on the AS as to

Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft

Thanks for the write up John and Mike! 1. Editorial: I'd add something like the following to the last paragraph in section 2. "However, if the authorization server does not support OAuth Discovery, then it MUST publicly define it's AS issuer URI." The point being that the client has to have a

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Security: OAuth Open Redirector

+1 On 1/25/16 1:41 PM, Phil Hunt wrote: Also, I would like to have a discussion in the WG around organization of the docs. What can we amend as errata (to give some of this stuff more prominence), and what new docs we should have? With PKCE, mix-up, and this, we may end up causing more

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

ent URI that is being used to scope the client_id? John B. On Jan 25, 2016, at 12:30 PM, George Fletcher <gffle...@aol.com <mailto:gffle...@aol.com>> wrote: I'm still catching up... but to this point specifically... Doesn't this require that the same client_id NOT be used simulta

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

oauth security for dynamic scenarios. "Dynamic" being broadly defined to mean: * clients who have configured at runtime or install time (including clients that do discovery) * clients that communicate with more than one endpoint * clients that are deployed in large volu

  1   2   3   >