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

After reading this draft I think that this may be better off as an experimental draft and not a WG draft -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Tuesday, January 19, 2016 3:47 AM To: oauth@ietf.org Subject: [OAUTH-WG] Call for a

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

+1 From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of William Denniss Sent: Wednesday, January 20, 2016 6:30 PM To: John Bradley ; Phil Hunt (IDM) Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation +1 for adoption, this is important work. On Thu, Jan

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

This work had many issues in the OpenID WG where it failed why should this be a WG item here ? The does meet the requirements for experimental, there is a fine line between informational and experimental, I would be OK with either but prefer experimental, I don’t think that this should become a

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

I really think that this is a step backwards relative to technology and what the developers would accept. The Link Relations takes us back to the XML days, I thought we have all moved on from that and at least trying to move Oauth to JSON. I think if this were adopted we might be splitting the d

Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

I also think we are way far from last call (and surprised to see last call issued) on this document as it is still very complex for something that should be very simple -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Thursday, February

Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

y that have not been addressed. -Original Message- From: Mike Jones Sent: Thursday, February 18, 2016 10:18 AM To: Anthony Nadalin ; Hannes Tschofenig ; Phil Hunt ; John Bradley Cc: oauth@ietf.org Subject: RE: [OAUTH-WG] OAuth Discovery spec pared down to its essence It's the OAuth-

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

I would go with option A, option B introduces concepts/syntax that complicates the current Oauth model -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Friday, February 19, 2016 11:43 AM To: oauth@ietf.org Subject: [OAUTH-WG] Fixing the A

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

I hear that many folks don't want to add a mandatory crypto operation on the client side :-( -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley Sent: Tuesday, February 23, 2016 3:17 PM To: Roland Hedberg Cc: Subject: Re: [OAUTH-WG] Fixing the Autho

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

> The point of the WGLC is to finish standardizing the core discovery > functionality that’s already widely deployed. That may be widely deployed for OIDC but not widely deployed for OAuth. There are some authentication mechanism discovery for endpoint that really should not be in an OAuth stand

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Sure there is, it is as you have now made it far easier and the security considerations does not even address this From: Mike Jones Sent: Wednesday, February 24, 2016 10:22 AM To: Anthony Nadalin Cc: Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location As we’d discussed in person, there’s no

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

To: Anthony Nadalin ; oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-meta-07.txt Link relation is not at all XML. It is a step forward to RESTfulness. In the older version of the draft, I was using JSONized version of it as well, but I splitted it out for the

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

The relationship between AS and RS need to be scoped to “does this RS accept tokens from this AS” as a list is too much information that could be used in the wrong way From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Nat Sakimura Sent: Thursday, March 10, 2016 6:25 PM To: Phil Hunt (IDM)

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

There have been way too many issues, confused conversations and discussions on and off list to have this document move forward, suggest that this be one of the main items on the agenda for when we meet. From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt (IDM) Sent: Thursday, Marc

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

and destination in the first place and returned both dst and scope in the response all along, so this is update that is consistent with the eisting architecture of OAuth 2. Lets keep the two issues separate. John B. On Mar 11, 2016, at 12:07 AM, Anthony Nadalin mailto:tony...@microsoft.com>

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

Sorry but not true, this started out as “discovery” and now it’s not From: Brian Campbell [mailto:bcampb...@pingidentity.com] Sent: Friday, March 11, 2016 3:59 PM To: Anthony Nadalin Cc: John Bradley ; oauth Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery That *is* the

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

From: Mike Jones Sent: Saturday, March 12, 2016 8:06 AM To: Anthony Nadalin ; Brian Campbell ; John Bradley Cc: oauth Subject: RE: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery The draft enables easy configuration of OAuth clients with an AS. For instance, the Microsoft “ADAL” OAuth

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

incomplete There are still documents from Nat, and I believe there will be one from Phil and maybe others. From: Mike Jones Sent: Saturday, March 12, 2016 8:29 AM To: Anthony Nadalin ; Brian Campbell ; John Bradley Cc: oauth Subject: RE: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery The

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

draft-hunt-oauth-bound-config-00.txt Date: March 13, 2016 at 3:53:37 PM PDT To: "Phil Hunt" mailto:phil.h...@yahoo.com>>, "Anthony Nadalin" mailto:tony...@microsoft.com>>, "Tony Nadalin" mailto:tony...@microsoft.com>> A new version of I-D, draft-hun

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

I would really like to see a comprehensive solution not this piece work, so we know what we are solving and what we are not. -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hans Zandbelt Sent: Monday, March 14, 2016 3:26 PM To: Phil Hunt (IDM) ; John Bradley C

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

uth 2.1 that describes the available extensions and when/why one would use them. On Mon, Mar 14, 2016 at 4:29 PM, Anthony Nadalin mailto:tony...@microsoft.com>> wrote: I would really like to see a comprehensive solution not this piece work, so we know what we are solving and what we are no

Re: [OAUTH-WG] [scim] Simple Federation Deployment

I would be interested also Sent from my Windows 10 phone From: Gil Kirkpatrick Sent: Wednesday, April 6, 2016 4:16 AM To: 'Nat Sakimura'; 'Hardt, Dick'; 'Phil Hunt (IDM)' Cc: s...

Re: [OAUTH-WG] [scim] Simple Federation Deployment server to server

6, 2016 5:52 AM To: Anthony Nadalin Cc: Gil Kirkpatrick ; Nat Sakimura ; Phil Hunt (IDM) ; s...@ietf.org; oauth@ietf.org Subject: Re: [scim] [OAUTH-WG] Simple Federation Deployment Sounds like there is interest. SCIM or OAUTH? -- Dick On Apr 6, 2016, at 8:57 AM, Anthony Nadalin mailto:tony

Re: [OAUTH-WG] Informal Discussion about Discovery Today at 16:20

Wasn't this the task of the design team ? -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Wednesday, April 6, 2016 10:48 AM To: oauth@ietf.org Subject: [OAUTH-WG] Informal Discussion about Discovery Today at 16:20 Hi all, during the f2f

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

I would like to see the multiple resources servers, interaction with Token Exchange resolved before this is adopted to see if this will actually solve the problems From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell Sent: Wednesday, April 6, 2016 12:52 PM To: Phil Hunt (IDM)

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

: Wednesday, April 6, 2016 1:13 PM To: Anthony Nadalin Cc: Phil Hunt (IDM) ; oauth@ietf.org Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0 Multiple resources are there now. I have no idea what "interaction with Token Exchange" means. Can you please explain? On

Re: [OAUTH-WG] OAuth 2.1

I don't belive that scopes should be defined more precisely as this opaqueness was a design feature, I'm not seeing the reason why scopes need to be defined, as these are application specific. -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt

[OAUTH-WG] Token Binding and RFC5705

At the informal Token Binding meeting we had a discussion of Java servers supporting TB, the support would have to come out of JSSE, kere is the analysis on what it would take to change JSSE Implementing 5705 itself, would not take too long and appears to be pretty straightforward. The EKM is

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

So now you are adding more requirements for encryption ? The more this thread goes on shows how unstable and not fully thought out this draft is to go through WG adoption. From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell Sent: Monday, April 11, 2016 12:30 PM To: Nat Sakimu

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

So it’s an incomplete solution then ? From: Brian Campbell [mailto:bcampb...@pingidentity.com] Sent: Monday, April 11, 2016 1:34 PM To: Anthony Nadalin Cc: Nat Sakimura ; Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0 No, I'm not adding requirement

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

Nadalin ; Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0 +1 to Torsten’s point. And a reminder to Tony that call for adoption is the *start* of the document editing process, not the end. We’re not saying this is a complete solution with everything thought out when we

Re: [OAUTH-WG] Multi-AS State Re-Use

STATE can be anything, it does not have to be a NONCE so changing this would cause issues at this time for existing deployments From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Nat Sakimura Sent: Monday, May 9, 2016 7:34 PM To: Guido Schmitz ; oauth@ietf.org Subject: Re: [OAUTH-WG] Multi-

Re: [OAUTH-WG] Reminder: OAuth Security Workshop

Can I also suggest that a PayPal or Credit Card payment be added as a means as bank transfer for corporate folks is like impossible -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Monday, May 16, 2016 4:25 AM To: Hannes Tschofenig ; oauth@ietf

Re: [OAUTH-WG] closing an open issue about supplementary info in the Token Exchange request

Sounds appropriate From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell Sent: Monday, June 20, 2016 10:16 AM To: oauth Subject: [OAUTH-WG] closing an open issue about supplementary info in the Token Exchange request A good while back in an off list conversation about Token Ex

Re: [OAUTH-WG] RT treatment in Token Exchange

So I think the proposed wording is still too specific and limits the use case , I also don’t understand the usage of “credential” in your description as this does not have to be a credential. So suggest that this be simple and if you want you can explain in the security considerations section wh

Re: [OAUTH-WG] OAuth Security -- Next Steps

Sounds about right, but I would imagine that the BCP would cover any issue that arises not just mix-up -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Monday, July 25, 2016 3:59 AM To: oauth@ietf.org Subject: [OAUTH-WG] OAuth Security --

Re: [OAUTH-WG] Call for adoption: Token Binding for OAuth 2.0

I’m OK with the https://tools.ietf.org/html/draft-jones-oauth-token-binding-00

Re: [OAUTH-WG] Following up on token exchange use case

Things have gotten so muddled not sure where to begin, the original goal of this draft was to provide the function that we use in daily high volume production of WS-Trust as we transition to Oauth. WS-Trust provided many options, one was ActAs and the other was OnBehalfOf, these were 2 distinct

Re: [OAUTH-WG] Authentication Method Reference Values Document: IPR Confirmation

I’m not aware of any IPR From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt (IDM) Sent: Tuesday, September 20, 2016 8:54 PM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Authentication Method Reference Values Document: IPR Confirmation I am aware of no IPR. Phil On

Re: [OAUTH-WG] Future of PoP Work

I would like to see us proceed with the symmetric PoP work in Oauth WG and stop the HTTP Signing work all together From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell Sent: Wednesday, October 19, 2016 12:54 PM To: Hannes Tschofenig Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] F

Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)

NIST asked for the addition of IRIS (as they are seeing more use of IRIS over retina due to the accuracy of iris) as they have been doing significant testing on various iris devices and continue to do so, here is a report that NIST released http://2010-2014.commerce.gov/blog/2012/04/23/nist-ir

Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)

and thus want tto make sure there is a way to distinguish during the authentication since the iris scan reduces the probability of error -Original Message- From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] Sent: Wednesday, February 1, 2017 4:15 PM To: Anthony Nadalin ; Mike Jones

Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)

We have interoped between FIDO authenticators vendors and Windows Hello -Original Message- From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] Sent: Wednesday, February 1, 2017 4:24 PM To: Mike Jones ; Anthony Nadalin ; joel jaeggli ; The IESG Cc: oauth-cha...@ietf.org; draft

Re: [OAUTH-WG] Call for adoption: OAuth Security Topics

I would be in favor of this -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Wednesday, February 1, 2017 11:10 PM To: oauth@ietf.org Subject: [OAUTH-WG] Call for adoption: OAuth Security Topics Hi all, this is the call for adoption of t

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-key-distribution-03.txt

I also think that this can be useful outside of Token Binding as this we have been looking at use cases for offline access tokens (or ID Tokens), and this sort of forms the basis for this approach From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Nat Sakimura Sent: Thursday, March 2, 2017

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-native-apps-08.txt

Not true John, the CTAP support that is current would support the web-view w/o any changes -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley Sent: Monday, March 6, 2017 12:16 PM To: Hannes Tschofenig Cc: internet-dra...@ietf.org; oauth@ietf.org Sub

Re: [OAUTH-WG] Updated Shepherd Write-Up for Native Apps document

I'm still getting feedback on the Windows examples that are pointed to by the spec, since it's not a simple case on Windows -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Monday, March 6, 2017 8:00 AM To: oauth@ietf.org Subject: [OAUTH

Re: [OAUTH-WG] Token Binding Presentations?

I'm unaware of any support for "OAuth" Token Binding from Microsoft, so I assume you are talking just about Token Binding cookies From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley Sent: Friday, March 17, 2017 10:43 AM To: Jim Manico Cc: IETF OAUTH Subject: Re: [OAUTH-WG] Tok

Re: [OAUTH-WG] Token Exchange - IPR Disclosure

I am not aware of any IPR on the token exchange document. From: Rifaat Shekh-Yusef [mailto:rifaat.i...@gmail.com] Sent: Thursday, November 23, 2017 8:14 AM To: draft-ietf-oauth-token-exchange@ietf.org; oauth Cc: Hannes Tschofenig Subject: Token Exchange - IPR Disclosure Authors, As part o

Re: [OAUTH-WG] Meeting Invite for the OAuth WG Virtual Office Hours

I was dialed in and no one was there From: OAuth On Behalf Of Hannes Tschofenig Sent: Monday, June 18, 2018 2:06 PM To: Brian Campbell Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Meeting Invite for the OAuth WG Virtual Office Hours Rifaat was on the call for 30mins but nobody joined. I couldn’t

Re: [OAUTH-WG] Call for adoption of "JWT Response for OAuth Token Introspection"

I’m concerned over the security implications of a client being able to introspect a token, for bearer tokens this can be very problematic, so unless the issues with possible token theft can be addressed I don’t support this as a WG draft From: OAuth On Behalf Of Rifaat Shekh-Yusef Sent: Thursd

Re: [OAUTH-WG] Revised Section 3

There is no extension in WRAP to allow this, it’s allowed as part of WRAP. From: William J. Mills [mailto:wmi...@yahoo-inc.com] Sent: Friday, April 22, 2011 4:10 PM To: Anthony Nadalin; Eran Hammer-Lahav; Dick Hardt Cc: OAuth WG Subject: Re: [OAUTH-WG] Revised Section 3 That WRAP allowed

Re: [OAUTH-WG] Closing a few issues

I propose that we close issue #12 (Restore WWW-Authenticate response to the framework specification) with no action, that is each extension would handle as they are doing now. -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Barry Leiba Sent:

Re: [OAUTH-WG] Revised Charter

I think that a re-charter after would be a great idea -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Monday, May 09, 2011 4:17 AM To: Eran Hammer-Lahav Cc: oauth@ietf.org; oauth-...@tools.ietf.org Subject: Re: [OAUTH-WG

Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsection on assertions

I think that this will be better moved into a separate document on assertions (were both authorization and authentication are talked about) and not to include in 4.5.1 but would like to see a reference in 4.5.1 to the new document -Original Message- From: oauth-boun...@ietf.org [mailto:o

Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsection on assertions

- From: Brian Campbell [mailto:bcampb...@pingidentity.com] Sent: Wednesday, May 25, 2011 6:54 AM To: Anthony Nadalin Cc: oauth Subject: Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsection on assertions That is another way to approach it and I understand there has been some talk

Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsection on assertions

...@pingidentity.com] Sent: Wednesday, May 25, 2011 12:22 PM To: Anthony Nadalin Cc: oauth Subject: Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsection on assertions It's not exactly clear to me what that means. Near the end of the interim meeting on Monday there was a specific discu

[OAUTH-WG] Redirect Issues

The OAuth spec is somewhat silent about how a resource provider should perform a redirect as there are many ways to accomplish the redirect. We also discovered that since the HTTP specifications were somewhat vague on fragments that some HTTP client implementations strip the fragment, we have th

Re: [OAUTH-WG] Updated text for Native Apps

Since Torsten and I had the action item to propose text we will update the text based upon the list and give you back an update From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Wednesday, June 15, 2011 9:33 AM To: Chuck Mortimore; oauth@ietf.org S

Re: [OAUTH-WG] Updated text for Native Apps

text as there is not consensus to do that, since there was an action item to put text back in. From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Wednesday, June 15, 2011 10:19 AM To: Anthony Nadalin; Chuck Mortimore; oauth@ietf.org Subject: RE: Updated text for Native Apps This working

Re: [OAUTH-WG] New Assertion Draft for review

This also moves the client_credentials authentication material out of the core and into a core companion specification. From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Saturday, June 18, 2011 1:08 PM To: Chuck Mortimore; oauth@ietf.org Subject: Re: [OAU

[OAUTH-WG] Native Application Text

9. Native Applications A native application is a client which is installed and executes on the end-user's device (i.e. desktop application, native mobile application, etc.). Native applications may require special consideration related to security, platform capabilities, and overall end-user e

Re: [OAUTH-WG] Native Application Text

28, 2011 6:36 PM To: Anthony Nadalin; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Native Application Text You text does not mention what will be a common use case, where the native app uses the password grant to fetch a refresh and access token. Whether or not an app can keep a secret

Re: [OAUTH-WG] security considerations - authorization tokens

When we constructed the current structure in Prague we thought that structure best fit the needs of a implementer, so my preference would be to keep it as it is now but, Torsten / Mark / Phil also may have feedback. -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ie

Re: [OAUTH-WG] security considerations - authorization tokens

[mailto:bea...@google.com] Sent: Thursday, July 07, 2011 10:59 AM To: Anthony Nadalin Cc: Eran Hammer-Lahav; oauth@ietf.org; Mark Mcgloin (mark.mcgl...@ie.ibm.com); Torsten Lodderstedt (tors...@lodderstedt.net); Phil Hunt (phil.h...@oracle.com) Subject: Re: [OAUTH-WG] security considerations

[OAUTH-WG] Redirection URI

Section 3.1.2 explicitly states that the redirection endpoint URI MUST be an absolute URI. But that means that the URI could be potentially of any scheme. This is probably intentional since there are scenarios where a native client will want to register a custom scheme as the call back URI.

[OAUTH-WG] State Size

The spec states in multiple places that servers control how big authorization and other codes are so clients can't be sure how much space they will have in URIs. How can anyone design a client that is intended to work with multiple authorization servers if they have no clue how big their state c

[OAUTH-WG] Refresh Tokens

Nowhere in the specification is there explanation for refresh tokens, The reason that the Refresh token was introduced was for anonymity. The scenario is that a client asks the user for access. The user wants to grant the access but not tell the client the user's identity. By issuing the refresh

Re: [OAUTH-WG] Refresh Tokens

Many reasons, but none are explained in the specification From: Dick Hardt [mailto:dick.ha...@gmail.com] Sent: Thursday, August 11, 2011 10:51 AM To: Anthony Nadalin Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Refresh Tokens My recollection of refresh tokens was for security and

Re: [OAUTH-WG] Refresh Tokens

Anonymity was certainly part of the design for WRAP From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Thursday, August 11, 2011 12:35 PM To: Anthony Nadalin; Dick Hardt Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Refresh Tokens Section 1.5 already covers refresh tokens. There

Re: [OAUTH-WG] Refresh Tokens

Section 1.5 does not explain why refresh tokens are there. If implementers don't understand why we did something then how are they supposed to get the implementation right? From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Thursday, August 11, 2011 12:35 PM To: Anthony Nadalin;

Re: [OAUTH-WG] Refresh Tokens

Could be! But a definite from Yaron. From: Dick Hardt [mailto:dick.ha...@gmail.com] Sent: Thursday, August 11, 2011 1:25 PM To: Anthony Nadalin Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Refresh Tokens If it was, no one told me. On 2011-08-11, at 12:41 PM, Anthony

Re: [OAUTH-WG] Refresh Tokens

There are no use cases at all in WRAP to help explain choices taken, it does not matter if there were or were not previous issues raised, it is being raised now. From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Thursday, August 11, 2011 1:46 PM To: Anthony Nadalin; Dick Hardt Cc

Re: [OAUTH-WG] Refresh Tokens

I’m raising the issue on the current text, I already provided text if the original append. From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Thursday, August 11, 2011 3:03 PM To: Anthony Nadalin Cc: Dick Hardt; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Refresh Tokens 1. Process

Re: [OAUTH-WG] Refresh Tokens

Disagree, this was our rational and this is one way it’s used today with our scenarios. This needs to be assigned an issue. From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Thursday, August 11, 2011 3:39 PM To: Anthony Nadalin Cc: Dick Hardt; OAuth WG (oauth@ietf.org) Subject: Re

[OAUTH-WG] x-www-form-urlencoded

In the text on the authorization and token endpoints an assumption is made that the query component of the URLs will be specified based on x-www-form-urlencoded. But in fact that is never explicitly stated. What is explicitly stated is that RFC 3986 section 3 has to be used (and then only for t

Re: [OAUTH-WG] Auth Code Swap Attack

quot;state" parameter. > Upon receiving the redirection request, the client MUST confirm that > returned value of the "state" parameter matches the value stored with > the resource owner's user-agent. > > > EHL > > > > > From: To

Re: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 from Yaron Goland

Agree, against the removal of text -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Lodderstedt, Torsten Sent: Thursday, August 18, 2011 1:01 AM To: Eran Hammer-Lahav; oauth@ietf.org Subject: Re: [OAUTH-WG] Partial set of last call comments on

Re: [OAUTH-WG] Auth Code Swap Attack

Concern here is we have a protocol that is open to attacks, we need to document a way that developers can safely implement, leaving it up to the developer may not be the best way unless they know what they are doing, so more in favor of recommending the use of state and if the developer can do

Re: [OAUTH-WG] Auth Code Swap Attack

RF tokens and other state information can be non-intuitive or complicated for some developers/platforms. EHL From: Eran Hammer-Lahav Sent: Friday, August 12, 2011 2:53 PM To: Anthony Nadalin; OAuth WG (oauth@ietf.org<mailto:oauth@ietf.org>) Subject: Re: [OAUTH-WG] Auth Code Swap Attack This

Re: [OAUTH-WG] Auth Code Swap Attack

No that is not what I said; you seemed to have interpreted it that way, From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Thursday, August 25, 2011 9:54 AM To: Anthony Nadalin; Torsten Lodderstedt Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack Everyone

Re: [OAUTH-WG] Auth Code Swap Attack

Acceptable, but not ideal -Original Message- From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Sunday, September 04, 2011 4:20 PM To: William J. Mills; Anthony Nadalin; Torsten Lodderstedt Cc: OAuth WG (oauth@ietf.org) Subject: RE: [OAUTH-WG] Auth Code Swap Attack This is my

Re: [OAUTH-WG] Rechartering

If scoped right I don't see any issues with any of these proposed items fitting into this WG, the question will be do we have the band width to work on all these items, as some are big and some are fairly small and contained. May have to have some prioritized list of where people think these fit

Re: [OAUTH-WG] Rechartering

Could be 2 tokens that still fulfill the same scope just that each token is a subset of the requested scope. -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Monday, October 31, 2011 2:17 PM To: Dick Hardt Cc: OAuth WG;

Re: [OAUTH-WG] TLS version requirements in OAuth 2.0 base

I would agree as we ran into this from some of deployment we had. What is the driving factor here for 1.2 over 1.0? -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Rob Richards Sent: Thursday, November 17, 2011 3:07 AM To: Barry Leiba Cc: oaut

Re: [OAUTH-WG] Mandatory-to-implement HTTP authentication scheme

Making the draft-ietf-oauth-v2-bearer mandatory to implement gets us a bearer (unknown content and format) token from the authorization server, for the resource server this gets us a authentication scheme of bearer (unknown content and format) token, not sure where this gets us towards interop a

Re: [OAUTH-WG] TLS version requirements in OAuth 2.0 base

And if the servers don't implement the "should" on 1.0 how do we get deployments for the other actors that can't talk to 1.2 -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Barry Leiba Sent: Thursday, November 17, 2011 3:19 AM To: Rob Richards

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

I agree we have no plans to implement MAC if we wanted that we would have been happy with OAUTH 1.0a but that was not deployable -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Saturday, December 03, 2011 6:26 PM To: Barry Lei

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

Not really sure how you came to the conclusion that native mobile clients can't be confidential? As pointed out in section 3.7 of the http://www.ietf.org/id/draft-ietf-oauth-v2-threatmodel-01.txt there are guidelines that confidential clients should follow, but does not distinguish between nati

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

Agree contents looks good Sent from my Windows Phone From: Igor Faynberg Sent: 3/14/2012 4:26 PM To: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering Looks good and comprehensive to me. Igor On 3/14/2012 4:21 PM, Hannes Tschofenig wrote: > So, here

Re: [OAUTH-WG] Error Registry Consensus Call

Agree on a single registry From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of George Fletcher Sent: Monday, May 07, 2012 4:56 PM To: Hannes Tschofenig Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] Error Registry Consensus Call I agree that one registry is desired! On 5/7/

Re: [OAUTH-WG] New draft process / editor role

Why rant here, talk to the chairs or AD Sent from my Windows Phone From: Eran Hammer Sent: 6/8/2012 6:58 PM To: oauth@ietf.org WG (oauth@ietf.org) Subject: [OAUTH-WG] New draft process / editor role Today, a new draft of the OAuth 2.0 specification was published.

Re: [OAUTH-WG] New Text for Sec 3.2.1 & 4.1.3

Not sure why this has to be a MUST in section 3.2.1 as the token endpoint has to the choice to reject it either way (provided or not) From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley Sent: Sunday, July 01, 2012 2:22 PM To: oauth@ietf.org WG Subject: [OAUTH-W

Re: [OAUTH-WG] New Text for Sec 3.2.1 & 4.1.3

While the client may be forced to provide the client_id there are no requirements for the endpoint to process the client_id (or how that is done) so not sure what good the change actually does From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer Sent: Monday,

Re: [OAUTH-WG] New Text for Sec 3.2.1 & 4.1.3

I read 4.1.3 as the client_id just has to have been issued to a (or any) public client From: John Bradley [mailto:ve7...@ve7jtb.com] Sent: Monday, July 02, 2012 2:54 PM To: Anthony Nadalin Cc: Justin Richer; oauth@ietf.org Subject: Re: [OAUTH-WG] New Text for Sec 3.2.1 & 4.1.3 The chang

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

Hannes, thanks for drafting this, couple of comments: 1. HOK is one of Proof of Possession methods, should we consider others? 2. This seems just to handle asymmetric keys, need to also handle symmetric keys -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org]

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

:05 PM To: Anthony Nadalin Cc: Hannes Tschofenig; OAuth WG Subject: Re: [OAUTH-WG] Holder-of-the-Key for OAuth Hi Tony, I had to start somewhere. I had chosen the asymmetric version since it provides good security properties and there is already the BrowserID/OBC work that I had in the back of m

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

:34 AM To: Hannes Tschofenig Cc: Anthony Nadalin; OAuth WG Subject: Re: [OAUTH-WG] Holder-of-the-Key for OAuth I agree that there are use-cases for all of the proof of possession mechanisms. Presentment methods also need to be considered. TLS client auth may not always be the best option.

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

The key does not have to be bound to the channel, that is just one option, the key can be a negotiated key -Original Message- From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] Sent: Tuesday, July 10, 2012 9:12 AM To: Anthony Nadalin Cc: Hannes Tschofenig; John Bradley; OAuth WG

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

> Binding the key to the channel is arguably the most secure Not really, there are hardware options that give good security properties -Original Message- From: John Bradley [mailto:ve7...@ve7jtb.com] Sent: Tuesday, July 10, 2012 9:55 AM To: Hannes Tschofenig Cc: Anthony Nadalin; Han

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

metric key case, I would also be interested in key establishment methods as well When I say arguably, I expect you to argue. John B. Sent from my iPhone On 2012-07-10, at 1:01 PM, Anthony Nadalin <mailto:tony...@microsoft.com> wrote: Binding the key to the channel is arguabl

<    1   2   3   4   >