Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0

While this work addresses a gap in the existing OAuth specification set, I am very concerned that this incremental extension will lead to even more confusion around the areas of “scope”, “audience” and “resource server”. I think we should try to solve this problem via a framework that provides

Re: [OAUTH-WG] OAuth Discovery

+1 [quote] > > I would like to understand these broader requirements, use cases, and > security considerations first. > > > > Phil > [\quote] OAuth is being used in a *much* broader set of use-cases and contexts than OpenID connect. I think its very important to have a solution that ad

Re: [OAUTH-WG] PoP Architecture: IPR Confirmation

confirmed - prateek mishra > On Sep 16, 2015, at 6:27 PM, Kepeng Li wrote: > > Hi Phil, Justin, William, Prateek ahd Hannes, > > I am working on the shepherd writeup for the PoP Architecture document: > https://www.ietf.org/id/draft-ietf-oauth-pop-architectur

Re: [OAUTH-WG] Confusion on Implicit Grant flow

.@ietf.org]*On Behalf Of*John Bradley *Sent:*Monday, February 09, 2015 3:31 PM *To:*Prateek Mishra *Cc:*oauth@ietf.org <mailto:oauth@ietf.org> *Subject:*Re: [OAUTH-WG] Confusion on Implicit Grant flow Typically the implicit callback JS is part of the application that is already loaded and c

Re: [OAUTH-WG] Confusion on Implicit Grant flow

The implicit flow depends upon a subtle and little known aspect of browser behavior - that the URI fragment component isn't propagated across redirects. I havent checked this recently - but I am aware that several folks have found that some browser versions dont comply with this requirement.

Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

OpenID Providers *15.2.* <http://openid.net/specs/openid-connect-core-1_0.html#DynamicMTI> Mandatory to Implement Features for Dynamic OpenID Providers -- Mike -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Prateek Mishra Sent: Friday, June 13, 2014 9:24 AM

Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

Excellent, now you have put your finger on the precise issue with OIDC - lots of optional extensions and shiny trinkets and lack of a clear definition of a core subset for servers. I realize its exciting for consultants, software and toolkit vendors to have that sort of optionality, but in pra

Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

! There is no question in my mind that the review within IETF would be more comprehensive and expose the work to a larger community. - prateek On 6/12/2014 12:49 PM, Prateek Mishra wrote: The OpenID Connect 2.0 COre specification alone is 86 pages. It has received review from maybe a dozen

Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

The OpenID Connect 2.0 COre specification alone is 86 pages. It has received review from maybe a dozen engineers within the OpenID community. The a4c draft proposal is 15 pages and will receive review from 100s of engineers within the world's most advanced standards body the IETF. It's a no b

Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

+1 to Hannes comments. Hi Mike, thanks for your quick response. On 06/05/2014 07:46 PM, Mike Jones wrote: Hannes, the Access Token and ID Token do quite different things and have different structures and properties. The Access Token is an opaque value that grants access to resources. An ID

Re: [OAUTH-WG] Client authentication and assertion grants

The difference between the two scenarios is that the authorization code has a one-use property and also requires the user to be present. These conditions are not available in the (assertion grant --> access token) with a public client. So there are some fundamental differences in security prop

Re: [OAUTH-WG] Client authentication and assertion grants

Sergey - you haven't missed anything. The client remains unregistered throughout the exchange. There is no relationship between the assertion grant (or access token) and the client either. You are pointing out that an AS endpoint supporting unregistered clients (public in OAuth terminology) f

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

Anil, the challenge is that OIDC is a rather large set of specifications, and to my knowledge even the core specification has NOT found a complete implementation at any large IdP. I am not talking here about boutique toolkits or startups, I am talking about the folks who have 100s of millions o

Re: [OAUTH-WG] Fwd: HTTP protocol version in MAC signatures

I hate to be one of these "lets-be-careful" guys, but I do have to point out that the AWS documentation and method being referenced is proprietary with its all attendant IP issues. - prateek Hi Hannnes, Yes, so in terms of well-defined specs for HTTP request signing, there is basically AWS,

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-pop-architecture-00.txt

"key confirmed" or "key confirmation" is another term that is widely used for these use-cases I really *like* the name "proof of possession", but I think the acronym PoP is going to be confused with POP. HOTK has the advantage of not being a homonym for aything else. What about "Possession Proo

Re: [OAUTH-WG] CORS and public vs. confidential clients

Bill - as you are referencing CORS in your message, I assume you are discussing a Javascript-only (browser) client. I believe the implicit flow was designed for this case and this flow never involves a confidential client. Confidential clients may be used with the other flows (code, resource,.

Re: [OAUTH-WG] Suitable grant type for a Javascript use case

steal the primary credentials from the auth server connection directly -- so the counter argument is a bit of a red herring. Yes, it's a requirement for this to work properly, but it's a requirement for many other things to work properly also. -- Justin On Feb 5, 2014, at 1:33 PM, P

Re: [OAUTH-WG] Suitable grant type for a Javascript use case

Well, this means you are completely dependent on a security model that is based on a very specific property of HTTP redirects. The User agent MUST NOT forward any component of a fragment URI in a redirect - you are depending on the user having a conformant and uptodate user agent. I would say t

Re: [OAUTH-WG] [Technical Errata Reported] RFC6749 (3880)

Well, the proposed correction does point to a genuine security hazard Specifically, when client instances share the same re-direct URI, typically mobile clients this is independent of whether implicit or code flows are used It is only injective clients - each of whose instances bind to unique

[OAUTH-WG] FYI: The Java Identity Api - public review ongoing

ABSTRACT: The objective of this project is to define application programming interfaces and identity interaction models to facilitate the use and creation of identity by Java applications. To meet this objective, this specification defines a /representation for identity/ in Java, an /attribut

Re: [OAUTH-WG] Joint meeting @IETF88: OAuth 2.0 Interop Strategy and Planning and OpenID Connect

Karen, I am planning to attend the meeting on Sunday. However, I have made my travel plans based on your previous announcement of 9/20 [quote] 2. Hold a oauth interop planning meeting in Vancouver in conjunction with IETF#88. This meeting is planned for: Sunday, 3 November, 2013, 2:00 pm -

Re: [OAUTH-WG] Fwd: [oauth-interop] scope and reach of testing activity

with_POST>/is testing pure OAuth functionality. -- Mike *From:*oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf Of *Anthony Nadalin *Sent:* Tuesday, October 08, 2013 4:22 AM *To:* Prateek Mishra; IETF oauth WG *Subject:* Re: [OAUTH-WG] Fwd: [oauth-interop] scope and r

[OAUTH-WG] Fwd: [oauth-interop] scope and reach of testing activity

, 04 Oct 2013 16:48:50 -0700 From: Prateek Mishra Organization: Oracle Corporation To: oauth-inte...@elists.isoc.org Hello OAuth Interop list, I would be interested in kicking off a discussion around the definition of scope and reach of the proposed testing activity. OAuth interop, of

Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-tcse-00.txt

Nat - is there cryptanalysis of the proposed model available anyplace? Extending protocols by throwing in a smidgen of hashing and a tablespoon of encryption is often a bad idea. One of the strengths of /RFC/ 6749 is that it avoids stuff like that. What do you mean when you say - [quote] The

Re: [OAUTH-WG] WGLC on JSON Web Token (JWT)

1) As a JWT is always an instance of JWE or JWS, I am not sure why there is a need for the the materials found in Section 5, para 1 (these are also found in the JWE and JWS draft specifications). It could simply be removed from the draft. 2) Why do we need both a "typ" claim and a "typ" header

Re: [OAUTH-WG] Fwd: New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt

Nat - your blog posting is helpful to those of us who are looking for a minimal extension of OAuth with an authenticator. Many implementors are seeking a modest extension of OAuth, not an entire new protocol stack. I believe that is the point of Phil Hunt's proposal to the OAuth committee.

Re: [OAUTH-WG] SAML-like ActAs

Hi Manfred, This is an area of interest to us and we have done some profiling in our implementation. Generally speaking, we work with the assertion profiles as a starting point. They allow for WS-Trust like token exchanges and (implicitly) support ActAs or OnBehalfOf. But they do need additi

Re: [OAUTH-WG] AS associated to multiple IdPs

Todd - doesnt the AS have adequate "scope" information to guess which resource server the token might get delivered to? I am afraid thats about as far as the OAuth flows go in capturing the "target" of the final request. Couldn't the "scope" information be used by the AS to decide between inc

Re: [OAUTH-WG] Proposed resolution - Dynamic Reg - Fix to client_id definition issue (was: Client Instances)

Well, I have to say that if anything seems poorly thought out, it would be a design with the following characteristics. [quote] We already have a "software_id" field and it's named "redirect_uris" [\quote] This seems to violate the most basic principles of software design - overloading a field

Re: [OAUTH-WG] Registration: Scope Values

+1 I think that the existing wording is superior to the proposed changed wording. The existing wording is: scope OPTIONAL. Space separated list of scope values (as described in OAuth 2.0 Section 3.3 [RFC6749] ) that the clien

Re: [OAUTH-WG] the meaning of audience in SAML vs. OAuth

Agreed, Chuck - I need to respond to Brian's message of Feb 14 and suggest proposed text for the draft. I plan to get to it in the next day or two. - prateek Hey Prateek - and suggested improvements for the SAML Bearer draft? On Mar 21, 2013, at 1:28 PM, prateek mishra wrote: Mike

Re: [OAUTH-WG] the meaning of audience in SAML vs. OAuth

cerned about the liability. Nat 2013/3/15 Mike Jones: The JWT meaning of the term "audience" is intended to be the same as SAML. Suggested wording clarifications would be welcomed. -- Mike -Original Message- From: prateek mishra [mailto:prat

[OAUTH-WG] the meaning of audience in SAML vs. OAuth

, at 11:34 AM, prateek mishra wrote: Hi Hannes, I wanted to point out that use of the term "audience" in this document is not consistent with the SAML 2.0 specification. What you are referring to here as "audience" corresponds to which is described as [quote-saml2.0

[OAUTH-WG] comment on draft-tschofenig-auth-audience-00.txt (incorrect use of audience)

Hi Hannes, I wanted to point out that use of the term "audience" in this document is not consistent with the SAML 2.0 specification. What you are referring to here as "audience" corresponds to which is described as [quote-saml2.0] Destination [Optional] A URI reference indicating the addr

[OAUTH-WG] Support for SAML assertion reference formats in OAuth SAML Assertion profile

SAML supports a couple of SAML assertion reference formats, wherein assertions are passed by reference. One format is the artifact, which can be carried by a thisisanartifact element Another possibility is the SAML URI binding which supports references of the form (abcde is a SAML id) GET

Re: [OAUTH-WG] OAuth2 attack surface....

On Mar 1, 2013, at 4:00 PM, prateek mishra wrote: Yup, use of confidential clients and full checking of redirect URIs would mitigate these attacks. I think there is an issue of providing guidance to developers/deployers, about making secure choices, that needs to be addressed someplace

Re: [OAUTH-WG] OAuth2 attack surface....

. John B. On 2013-02-28, at 2:56 PM, prateek mishra <mailto:prateek.mis...@oracle.com>> wrote: Characteristics of both these attacks - 1) Use of implicit flow (access token passed on the URL) 2) changes to redirect uri (specification does allow some flexibility here) 3) applications with l

Re: [OAUTH-WG] OAuth2 attack surface....

Characteristics of both these attacks - 1) Use of implicit flow (access token passed on the URL) 2) changes to redirect uri (specification does allow some flexibility here) 3) applications with long-lived access tokens with broad scope (in one case only) - prateek And a different one (still ex

Re: [OAUTH-WG] Fw: IPR Disclosure: - What to Do with JWT ?

Two points - 1) I request that this mailing list NOT be used for any substantive discussion of patent claims and so on. This will create difficulties for many participants and I dont believe is within the charter of this effort. 2) I would encourage interested parties to review the following

Re: [OAUTH-WG] JWT - scope claim missing

SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants Assertion Framework for OAuth 2.0 a bit wordy, but does get the point across IMO - prateek I'm not sure anyone really "picked" the titles for t

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

ey to the RS would work but relays on an implicit assumption about what RS the client may present the token to otherwise all the RS have to share private keys(probably a bad thing) John B. On 2013-02-14, at 4:20 PM, Prateek Mishra wrote: Justin - my comment was scoped to *key distribution* - n

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

Justin - my comment was scoped to *key distribution* - not to the general use of public clients. I was wondering how one can distribute keys or have key agreement between an AS and a client, if there is no existing trust relationship between them. Maybe there is some clever crypto way of achie

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

supported bearer model would be valuable. In these cases, the AS and RS belong to the same administrative domain. - prateek Hi Prateek, thanks for your questions. On Feb 13, 2013, at 6:13 PM, Prateek Mishra wrote: Hannes, 1) Its not clear to me that we need to specify exchanges between

[OAUTH-WG] comments on draft-ietf-oauth-saml2-bearer-15

It would be helpful if the draft identified the various cases that are intended to be supported. For example, in draft-ietf-oauth-assertions-10, there is a helpful distinction made between "Client acting on behalf of a user" vs. "Client Action on behalf of an anonymous user" (vs. even more advanc

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

key at the point where an access token is issued by the AS. 3) I think do need an MTI key distribution protocol as part of the specification, leaving that as a choice would hurt interoperability. - prateek Here are my notes. Participants: * John Bradley * Derek Atkins * Phil Hunt * Prat

Re: [OAUTH-WG] conf call follow up from today

Bill - How does OAuth 1.0a deal with the problem of HTTP URL and header mutability? Header order may get re-arranged and URLs modified in transit from client to server. As a result, the signature/HMAC might not validate at the final destination. Isn't that a foundational problem with the OAut

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

Can you explain how SSLstrip could be used to defeat the OAuth flows? Isn't it dependent on web pages with non-HTTPs links? Which step in the OAuth exchanges would be vulnerable? BTW, there is a threats analysis document that discusses a variety of attacks and countermeasures - http://datat

Re: [OAUTH-WG] Please review draft-ietf-oauth-json-web-token

Hannes - here a couple of comments on the 05 draft - (i) Section 4 - [quote] Note however, that the set of claims that a JWT must contain to be considered valid is context-dependent and is outside the scope of this specification. When used in a security-related context, implementations MUST und

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

Pedro - the best way to move this forward is to make a proposal or describe some use-cases. My own guess is that we also need a broader discussion of different client-types and their deployment models. For example, there are clients that are delivered through a secured process to tablets or d

[OAUTH-WG] (no subject)

Sent from my Verizon Wireless Phone___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

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

+1 finishing a draft for historical reasons without the full context of HoK use-cases and identified threats concerns me In Vancouver the question was asked about the future of the MAC spec due to it no linger having a editor. The Chair and AD indicated a desire to have a document on the u

Re: [OAUTH-WG] Holder-of-the-Key for OAuth

symmetric key to use for the signature check, but that could just be included in token anyway without holder-of-key. I really don't see how this works with symmetric keys in any useful way that's not easier via another method like MAC tokens? From: prateek mishra To: "Tschofenig,

Re: [OAUTH-WG] Holder-of-the-Key for OAuth

.@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf Of *ext prateek mishra *Sent:* Tuesday, July 10, 2012 8:42 PM *To:* oauth@ietf.org *Subject:* Re: [OAUTH-WG] Holder-of-the-Key for OAuth As Phil Hunt suggests, there is a need for a discussion of the use-cases involved How to bind the key to the

Re: [OAUTH-WG] Holder-of-the-Key for OAuth

As Phil Hunt suggests, there is a need for a discussion of the use-cases involved How to bind the key to the requestor may have several variations, I would hope the work would cover a broad range Given the importance of the symmetric key case, I would also be interested in key establishment

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

Francisco, You are right, I was in error to suggest that it was a MUST. I think my main concern was that security considerations should not be based on polling developers/deployers of an existing or legacy protocol. SAML does include some additional countermeasures though - for example (line

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

I would like to strongly disagree with this proposal. It amounts to explicitly making OAuth 2.0 insecure so as to satisfy some mysterious and unspecified set of legacy OAuth 1.0 deployments. The SAML web SSO (artifact) profile - which shares many characteristics with the initial steps in OAut

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

+1 on #3 from an enterprise perspective, we really dont want applications/clients to have embedded knowledge of the security model for any target resource. As I understand this proposal, this would allow a security component at the client site/device to discover and create the right type of t

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

George, I will comment at a later time on the details of your use-case. But as far as signing the request for a protected resource (signature over access token, client_id, scope, URL, request body) - isn't this requirement is a simple consequence of network architecture wherein an SSL connec

Re: [OAUTH-WG] specification of authorization code properties

k you for your advice. The Oauth security considerations are not finished yet. They will handle the issues you raised, too. Regards, Torsten. Am 30.09.2010 um 01:33 schrieb PRATEEK MISHRA : I read through v10 from the perspective of an implementor, and it seemed to me that properti

[OAUTH-WG] specification of authorization code properties

I read through v10 from the perspective of an implementor, and it seemed to me that properties of generated authorization code and its treatment by various entities need to be called out explicitly as a counter-measure against various simple attacks. I would also comment that the exchanges bet

Re: [OAUTH-WG] What's the use case for signing OAuth 2.0 requests?

Yaron, You have referenced the SAML browser SSO protocol (POST profile) in your blog posting, and correctly observed that the same problem would manifest itself there as well. As a counter-measure, the SAML POST profile explicitly requires that the target (destination) URL or similar ident

Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft

sessions. Hope that helps clarify. -cmort From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of Prateek Mishra [prateek.mis...@oracle.com] Sent: Wednesday, August 04, 2010 8:08 AM To: Brian Campbell Cc: oauth Subject: Re: [OAUTH-WG] SAML 2.

Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft

Brian, it would probably help to clarify that you are proposing this as a additional or follow-on step to SSO implemented via the SAML web browser profiles (right?). Maybe some text could be added to the draft to make that explicit. This is in contrast to more general token exchange scenario

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

Where is the meeting and at what time? [quote] This will be the last draft update before our meeting next week to allow everyone time to read it and prepare. EHL [\quote] ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinf

Re: [OAUTH-WG] User and Client identity in the Assertion Flow

SAML 2.0 assertions can represent a variety (very large) of relationships between the presenter, issuer, subject, means of confirmation and so on and so forth. So representing multiple identities - i am server foo but I am acting for joe - is not very difficult. We can profile these versus add

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

Eran, I want to support the idea of a minimal specification, that supports the basic use-case with no frills. Successful standards are usually small and with strong focus on a few key use-cases But the specification does need to point to or document some extensibilty points. Otherwise, imple

Re: [OAUTH-WG] Call for Consensus (Deadline: April 22)

Do you mean April 29 (Thu) and April 30th (Fri)? This is a call for consensus on accepting Eran's latest OAuth draft, draft-hammer-oauth2 [1] as a working group item. Assuming no objections by end-of-day Tuesday, April 22nd, this draft will be promoted to an active working group document on Wedne