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

tshirt or it didnt happen On 1/22/16 1:57 PM, John Bradley wrote: Now that we have a cool name all we need is a logo for the attack and per haps an anime character, and we are done with all the hard work:) John B. On Jan 22, 2016, at 2:54 PM, David Waite mailto:da...@alkaline-solutions.com>>

Re: [OAUTH-WG] IETF 95 - Buenos Aires

John, could you not supply a donkey to carry Hannes' luggage? or is it a BYOD instance? On 1/15/16 9:33 AM, John Bradley wrote: It is about a 13day walk with a really big hill (Andies) that he would need to get over. If he came a week early and had a water carrier he might make it depending

Re: [OAUTH-WG] OAuth Digest, Vol 81, Issue 86

Antonio, are you arguing for short token lifetimes and so frequent explicit consent ? or something more if the app has a valid refresh token then there is no opportunity for the AS to inject a consent screen paul On 7/24/15 3:00 AM, Antonio Sanso wrote: hi, nice to see some work on this to

Re: [OAUTH-WG] On Client credentials.

Hi Savita, the client credentials grant allows the Client to request an access token for *itself* (ie in its own right), rather than on behalf of a particular user (who is willing to delegate authorizations to the Client). paul On 3/8/15 8:21 PM, Savita D wrote: Hi, Its really good to see t

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

Standardized Introspection will be valuable in NAPPS, where the AS and RS may be in different policy domains. Even for single policy domains, there are enterprise scenarios where the RS is from a different vendor than the AS, such as when an API gateway validates tokens issued by an 'IdP' . We'

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

I support the WG taking this on 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 WG work ite

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

let's not this disagreement over the need & relevance of a4c be conflated with the age-old blurriness between authz & authn - in no way are the two related paul On 6/13/14, 7:50 PM, John Bradley wrote: To be precise SAML, Connect, and a4c provide Assertion-based authentication of a claimant,

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

Phil, neither is Connect an authentication mechanism, it (and SAML, WS-fed etc) is also a 'method for providing end-user authentication information to client applications' We don't need a Connect-- paul On 5/14/14, 1:29 PM, Phil Hunt wrote: This is not an authentication mechanism - it is a met

Re: [OAUTH-WG] OAuth & Enteprise federation ... 5 years from now

a variant I've seen proposed is to to have 1) the native app obtain tokens from AS1 2) the RS only accept tokens from AS2 3) have AS1 request tokens of AS2 on back-channel to meet reqs of #1 & #2 lots of ways to 'close the loop' paul On 3/27/14, 10:06 AM, John Bradley wrote: Hi Adam, 3 is th

Re: [OAUTH-WG] OAuth & Enteprise federation ... 5 years from now

Hi Adam, we are confronting this issue in the NAPPS effort and are exploring a model that resembles your Option 2 The Token Agent (TA) obtains an id-token from the first AS1, this targetted at the second AS2 (the one local to the target RS). The TA then exchanges that id_token at AS2 for an ac

Re: [OAUTH-WG] Should data exist for an Oauth access token request to be granted?

Hi Don, the way I see it, whether or not there is data available at the RS is mostly orthogonal to any authorizations the client is issued for that data But a caveat is the risk of Client's asking for 'omnibus scopes', ie any and everything on the possibility that the authorizations become r

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

I always think I pretty much understand OIDC until I see the specs list On 7/30/13 12:39 PM, Brian Campbell wrote: Yes, that. On Tue, Jul 30, 2013 at 4:46 PM, Richer, Justin P. > wrote: Yes, I agree that the giant stack of documents is intimidating and in my

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

why pigeonhole it? OAuth can be deployed with no authz semantics at all (or at least as little as any authn mechanism), e.g client creds grant type with no scopes I agree that OAuth is not an *SSO* protocol. On 2/5/13 3:36 PM, John Bradley wrote: OAuth is an Authorization protocol as many of

Re: [OAUTH-WG] Is "Allow / disallow" screen mandatory ?

there are legitimate (non consumer centric) applications of OAuth where such explicit consent gathering is not necessary On 8/3/12 9:23 AM, Jérôme LELEU wrote: Said like that, I feel totally stupid... but it's not totally without their consent, they previously clicked on the "Authenticate at th

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

#x27;s say a client generates multiple Access Tokens at the same time while generating new Refresh Token values during each "Token Refresh" operation. However I don't really see the useful of this case. Doug On Mon, Jun 11, 2012 at 3:52 P

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

n the new ones should be valid and the old ones potentially > revoked. > > Thanks, > George > > On 6/11/12 4:09 PM, Paul Madsen wrote: >> >> Hi Doug, my interpretation is that 'for that refresh token' means those >> access tokens issued in exchange for

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

Hi Doug, my interpretation is that 'for that refresh token' means those access tokens issued in exchange for that refresh token. Consequently, for the cases you cite below, the access tokens at the same time as a given refresh token need not be invalidated when that refresh token is 'processed

Re: [OAUTH-WG] Difference between RO and End User (Was: Few questions about client_credentials)

cloud, TV Everywhere, etc) the owner of the resource may be some other entity (the employee's enterprise, the video content owner, etc) paul On 5/11/12 10:04 AM, Sergey Beryozkin wrote: Hi On 01/03/12 22:36, Paul Madsen wrote: RO =/= end-user Can you please elaborate on the difference

Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token

Using the browser as part of the AS interaction allows you to more easily collect the users consent.  Once you get the tokens based on that consent, everything is 'RESTful' Original message Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token From: Lewis Adam-CAL022 To:

Re: [OAUTH-WG] Updated Charter to the IESG (this weekend)

Hi Hannes, do you mean 'discover relevant OAuth endpoints *for* a resource server'? ie instead of discovering the RS itself? On 4/12/12 6:55 AM, Hannes Tschofenig wrote: Hey guys based on the discussion before, during, and after the Paris IETF meeting I am going to send the following updated

Re: [OAUTH-WG] Using Oauth2 token to SOAP web services

mixed REST & SOAP environments dont necessarily require using OAuth tokens directly in SOAP headers - you can exchange the token for an equivalent SAML assertion (for which we already have a profile stipulating how to use in SOAP headers) We see alot of this - people leveraging existing SOAP

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

. >>> >>> Could you submit the document as Internet Draft when the submission gates >>> open again? >>> The I-D submission tool will be reopened at 00h UTC, 2012-03-26. >>> >>> From the current list of items what do you consider less important?

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

t of items what do you consider less important? Ciao Hannes *From:*oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf Of *ext Paul Madsen *Sent:* Thursday, March 15, 2012 12:35 PM *To:* Richer, Justin P. *Cc:* oauth@ietf.org WG *Subject:* Re: [OAUTH-WG] OAuth WG Re-Chartering +1

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

To Eran's point about the relevance of RS-AS standardization in internal vs external deployments, many of our customers are using our AS to issue tokens to their API clients, but an API management solution (from different vendor) to front their APIs. The API management soln becomes the RS and

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

June 2011 Appendix A. Contributors folks Appendix B. Document History [[ to be removed by RFC editor before publication as an RFC ]] 3. Normative References [I-D.ietf.oauth-v2] Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, "The OAu

Re: [OAUTH-WG] Are there any implementations of the SAML bearer token specificiation?

Ping Identity has implemented On 3/12/12 11:55 AM, Alex Bilbie wrote: Hello, Can anyone please tell me if there are any implementations of the OAuth 2 SAML bearer tokens draft specification? It is our intention to expand on the existing work (see http://lncn.eu/jsx5) we have done at the Un

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

+1 On 3/11/12 6:05 AM, Manger, James H wrote: +1 -- James Manger - Reply message -From: "Mike Jones" Date: Sun, Mar 11, 2012 4:50 am Subject: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer To: "Paul Madsen", "Brian Campbell"

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

+1 On 3/7/12 4:08 PM, Brian Campbell wrote: Yeah, it is case insensitive. I just went with the upper case B because that's how it was written in §5.1.1 of draft-ietf-oauth-v2-bearer-17* which is where I guess it's actually defined. But I see draft-ietf-oauth-v2-23 uses a lower case b**. Either o

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

as one of the unnamed 'confused colleagues', I'd welcome clarification paul On 3/6/12 11:23 AM, Brian Campbell wrote: Thanks Mike, I think changing the example would be helpful. However I think that including some text along the lines of what James suggested would also be very valuable. I agre

Re: [OAUTH-WG] Few questions about client_credentials

RO =/= end-user On 3/1/12 5:33 PM, Zeltsan, Zachary (Zachary) wrote: Are you saying that this can include the resources of possibly different end users ? Yes. The specification does not limit a number of the users whose resources a client may access using the client credentials flow. Zachary

Re: [OAUTH-WG] Access Token Response without expires_in

tedt [tors...@lodderstedt.net] *Sent:* Tuesday, January 17, 2012 12:26 PM *To:* Paul Madsen *Cc:* oauth-boun...@ietf.org; Richer, Justin P.; OAuth WG *Subject:* Re: AW: Re: [OAUTH-WG] Access Token Response without expires_in Hi Paul, that's not what I meant. The Client should know which tokens shou

Re: [OAUTH-WG] Access Token Response without expires_in

. *From:* Paul Madsen *To:* "Richer, Justin P." *Cc:* OAuth WG *Sent:* Tuesday, January 17, 2012 5:23 AM *Subject:* Re: [OAUTH-WG] Access Token Response without expires_in Separate from the question posed here, we

Re: [OAUTH-WG] Access Token Response without expires_in

eturn expires_in because this would not make any sense in this case. regards, Torsten Paul Madsen schrieb: Hi Torsten, yes the use case in question is payment-based as well. Your suggestion for the client to infer one-time usage from a missing expires_in contradicts the ge

Re: [OAUTH-WG] Access Token Response without expires_in

What would such an extension specify? regards, Torsten. Gesendet mit BlackBerry® Webmail von Telekom Deutschland -Original Message- From: Paul Madsen Sender: oauth-boun...@ietf.org Date: Tue, 17 Jan 2012 08:23:37 To: Richer, Justin P. Cc: OAuth WG Subject: Re: [OAUTH-WG] Access Token Res

Re: [OAUTH-WG] Access Token Response without expires_in

Separate from the question posed here, we are seeing customer demand for one-time semantics, but agree with Justin that this would best belong in a dedicated extension parameter and not the default paul On 1/16/12 10:29 PM, Richer, Justin P. wrote: I think #3. #1 will be a common instance, a

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

binary is good enough. They will be wrong, but the spec allows them to make that decision. EHL *From:*oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf Of *Paul Madsen *Sent:* Monday, December 19, 2011 4:19 AM *To:* oauth@ietf.org *Subject:* [OAUTH-WG] Native clients & '

Re: [OAUTH-WG] OAuth2 security considerations for client_id

William, presumably you meant 'client_secret'? And is it fair to say that this reflects the current reality (of app distribution channels & OS protections) more so than any inherent mobile client limitation? paul On 1/6/12 12:34 PM, William Mills wrote: Yeah, certainly for Mobile clients thi

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

thanks John, inline On 12/19/11 3:20 PM, John Kemp wrote: Hey Paul, On Dec 19, 2011, at 2:49 PM, Paul Madsen wrote: Hi John, the user identity& credentials are definitely fundamental (they allow the video content to be personalized), but given the valuable nature of the resources b

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

d" part sort of breaks the "bearer" part:) yeah, how do we bind a bearer token to anything? :-) Doesnt that by definition take us towards MAC? Thanks, George On 12/19/11 1:09 PM, Paul Madsen wrote: Thanks Justin, FWIW, I agree with your analysis Seems to me we have the following br

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

rote: Hi Paul, On Dec 19, 2011, at 12:50 PM, Paul Madsen wrote: Hi Mike, to some extent I think my question is not about specific security characteristics, but rather whether its realistic for our group to mandate that both server& native clients have the *same* security characteristics -

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

client and trade an authz code for the token. *Ideally*, all our clients would be confidential, and so capable of authenticating to the AS to prevent/mitigate the above risk thanks paul On 12/19/11 1:00 PM, Michael Thomas wrote: On 12/19/2011 09:50 AM, Paul Madsen wrote: Hi Mike, to some

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

ly help. OAuth 1.0 only had "confidential" clients, and that led to inane workarounds like Google's "anonymous/anonymous" client id/secret. Hope this helps. -- Justin On 12/19/2011 07:19 AM, Paul Madsen wrote: Hi, the Online Media Authorization Protocol (OMAP) is a

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

to the AS on the token endpoint. thanks paul On 12/19/11 12:18 PM, Michael Thomas wrote: On 12/19/2011 04:19 AM, Paul Madsen wrote: Hi, the Online Media Authorization Protocol (OMAP) is a (as yet unreleased) profile of OAuth 2.0 for online delivery of video content based on a user's su

[OAUTH-WG] Native clients & 'confidentiality'

Hi, the Online Media Authorization Protocol (OMAP) is a (as yet unreleased) profile of OAuth 2.0 for online delivery of video content based on a user's subscriptions (the TV Everywhere use case) We want to support both server & native mobile clients. It is for the second class of clients that

Re: [OAUTH-WG] Mandatory-to-implement token type

Commercial OAuth authorization servers are neither 'toolkits' nor 'purpose built code' - not used to build OAuth clients/servers but yet required to support more variety in deployments than a single purpose built server. But, that variety is driven by customer demand, and none of ours (yet?)

[OAUTH-WG] Typo in Section 5.1 of 21

scope OPTIONAL. The scope of the access request as described by Section 3.3 <http://tools.ietf.org/html/draft-ietf-oauth-v2-21#section-3.3>. presumably this should be 'access token' paul -- *Paul Madsen* *Ping Identity* www.

[OAUTH-WG] Typo in Sec 5.1

scope OPTIONAL. The scope of the access request as described by Section 3.3 . presumably this should be 'access token' paul ___ OAuth mailing list OAuth@ietf.org https

Re: [OAUTH-WG] problem statement

that is the original problem statement, but surely no longer the only one On 9/6/11 2:10 PM, Igor Faynberg wrote: Mike, You've got the problem statement right: allowing the user to authorize resource access to another party without divulging user's credentials is the objective of OAuth. You

Re: [OAUTH-WG] access/refresh token scope ambiguity

presumably should be if the *returned* scope is different from the one requested by the client. On 6/27/11 11:47 AM, Andrew Arnott wrote: I was looking at the scenario of using a refresh token to obtain a new access token, and noticed that in draft 16, Section 5.1 "Successful Response" describ

Re: [OAUTH-WG] bearer token authorization header

Mike/George, can you clarify in what sense must a client and RS agree on the format of a bearer token? Are they not opaque to the client, and so their internal format irrelevant to it? paul On 5/24/11 4:04 PM, Mike Jones wrote: George, you are correct that resources and clients must agree upo

Re: [OAUTH-WG] Paper for the W3C Identity in the Browser Workshop about OAuth

enig wrote: In some sense you are right. The problem is just that this is the name of the group :-) http://datatracker.ietf.org/wg/oauth/charter/ Maybe we should adjust the name with the rechartering process. On Apr 27, 2011, at 6:17 PM, Paul Madsen wrote: 'Open Web Authenti

Re: [OAUTH-WG] Paper for the W3C Identity in the Browser Workshop about OAuth

'Open Web Authentication protocol'? authentication? On 4/27/11 11:06 AM, Hannes Tschofenig wrote: Hi guys, Barry, Blaine and I compiled a short position paper for the upcoming W3C identity in the browser workshop. Here is the call for participation: http://www.tschofenig.priv.at/svn/w3c-bro

Re: [OAUTH-WG] draft-15 editorials

fit what you were after? Your "directly negotiate access" phrase hints that there is more to OAuth 2 than delegation, but I'm not sure that it explains it. -- James Manger *From:*oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf Of *Paul Madsen *Sent:* Thursda

Re: [OAUTH-WG] draft-15 editorials

g [mailto:oauth-boun...@ietf.org] *On Behalf Of *Paul Madsen *Sent:* Wednesday, April 06, 2011 4:00 AM *To:* oauth@ietf.org *Subject:* Re: [OAUTH-WG] draft-15 editorials Can we not acknowledge in the abstract that there are other applications for OAuth beyond the delegated authz scenario? I tell pe

Re: [OAUTH-WG] draft-15 editorials

Can we not acknowledge in the abstract that there are other applications for OAuth beyond the delegated authz scenario? I tell people that OAuth 2 is more a framework than a specific protocol, but the current abstract belies this claim. paul On 4/5/11 8:57 PM, Mike Jones wrote: Also, chang

[OAUTH-WG] (late) feedback on draft-ietf-oauth-v2-13.txt

In Section 6. Refreshing an Access Token (http://tools.ietf.org/html/draft-ietf-oauth-v2-13#section-6) the text refresh_token REQUIRED. The refresh token issued along the access token being refreshed. seems both somewhat contorted and somewhat misleading Suggest 'along' --> 'along

Re: [OAUTH-WG] Freedom of assembly for response_type

Breno, why are you using 'cookie' in this context? SAML's 'session management' (I assume you are referring to SLO?) functionality does not rely on browser cookies, but rather on the participants sending a LogoutRequest carrying an identifier for the Subject in question (and possibly a session

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

Prateek, I believe that here it is the SAML IdP that acts as OAuth Client, not SAML SP - the point of the flow is to get the Assertion (that the IDP would normally send through the browser) over to the SP through an OAuth request/response exchange (in order to get an OAuth token) paul On 04/

[OAUTH-WG] Extensibility model in 07?

Hi Eran, you indicated last week there would be a first cut of an extensibility model in 07. Deferred to 08? Thanks ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Assertion flow and token bootstrapping

I think STS was used in the generic sense, ie token in, token out Although a SOAP-binding for the flow would be wonderfully perverse paul On 03/06/2010 10:54 AM, Thomas Hardjono wrote: Dick, Brian, Thanks for the clarification. - Is the Assertion Flow designed only for the STS, or can it be

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

Torsten, have you thought about the relevance of the for identifying the client? Identify if not authenticate. On 5/13/2010 6:38 AM, Torsten Lodderstedt wrote: In my perception, we reached consensus in the thread "Autonomous clients and resource owners (editorial)" that the assertion flow s

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

But client_secret is not defined specific to a given flow - its used by the web server, user name, and client credentials flows. I can find no mention of the client using the client_secret for crypto authentication - the text of 5.3 'Crypto Tokens Requests' is very specific to clients authenti

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

r hand, the AS creates the QR code from a URI it generates, then the phone need only launch a browser to load that URI. paul On 5/11/2010 4:55 PM, Marius Scurtescu wrote: On Tue, May 11, 2010 at 4:12 AM, Paul Madsen wrote: Yes that's the idea. Where in the authorization server

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

curtescu wrote: On Mon, May 10, 2010 at 6:20 AM, Paul Madsen wrote: Related, is anybody thinking of a variant of the device flow where the user-agent sits on a device with QR-code capabilities, and so the user needn't type anything (uri or code)? The end user will point their phone t

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

some feedback wrt the device flow - 'verification URI' and 'authorization URI' are used interchangeably - in the example messages, the verification code the client sends on its request for an access token is 'J2vC42OifV', not the same as that previously issued by the authorization server, name

Re: [OAUTH-WG] First draft of OAuth 2.0

Separate from the Client trading a SAML assertion for an Access Token as in this flow, we are interested in defining how a Client might use SAML SSO messages to get an Access Token (comparable to OpenID/OAuth hybrid). Anybody else interested? paul On 3/23/2010 1:47 PM, David Recordon wrote: