[OAUTH-WG] Where to send typo feedback?

e. Thanks. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Google and Facebook not preserving querystrings?

Is there any validity to this claim<http://stackoverflow.com/questions/10436924/are-querystring-parameters-supported-in-oauth-2-0-redirect-urls> ? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it.&quo

[OAUTH-WG] How an AS can validate the state parameter?

er it an opaque value. How then, can an AS validate and sanitize the state parameter? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre ___ OAuth mai

[OAUTH-WG] Section 10.3 client advice inapplicable?

hts than requested. I can't find the part in the spec where the client can request access tokens in such a way as to influence the lifetime. Why is the client then being advised in the above section to minimize the lifetime of the access tokens it asks for? -- Andrew Arnott "I [may] n

Re: [OAUTH-WG] Reconciling section 2.2 with 3.2.1

or the purpose of providing user context, statistics, etc. > > ** ** > > EH > > ** ** > > *From:* oauth-boun...@ietf.org 'oauth-boun...@ietf.org');> [mailto:oauth-boun...@ietf.org 'cvml', 'oauth-boun...@ietf.org');>] > *On Behal

[OAUTH-WG] Clarification on section 3.3: missing scope parameter in access token request

cope is simply the maximum scope allowed by the grant) Thanks. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre ___ OAuth mailing list OAuth@ietf.org http

[OAUTH-WG] Reconciling section 2.2 with 3.2.1

thentication > > A public client that was not issued a client password MAY use the > client_id request parameter to identify itself when sending requests to > the token endpoint. Thanks. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the d

Re: [OAUTH-WG] OAuth2 and clients without browsers

Yes, thank you. I'm glad there's already a spec for this. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre On Tue, Jul 26, 2011 at 4:29 PM, Marius Scurtescu wrote: > I think y

Re: [OAUTH-WG] OAuth2 and clients without browsers

Trying a different DL... -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre On Wed, Jul 20, 2011 at 6:38 AM, Andrew Arnott wrote: > The recent OAuth 2 specs seem to omit the scenario of a

[OAUTH-WG] access/refresh token scope ambiguity

ope), would the scope parameter in the section 5.1 response match the scope of the newly issued refresh token or the newly issued access token? I'm hoping the spec can be beefed up to remove any ambiguity here. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll def

Re: [OAUTH-WG] Fwd: [oauth] Good list of OAuth open source?

nt area of the spec among recent drafts). -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre On Sat, Jun 25, 2011 at 2:25 AM, Teo Hui Ming wrote: > Thanks for sharing, the code looks pretty neat!

[OAUTH-WG] OAuth 1.0 2-legged scenario

. The fact that the client has no consumer secret is of little consequence because the access token secret is unique for this particularly installation of the client and therefore the data is protected. So... which one is right? And does the "wrong" one have any validity? Thanks. -

Re: [OAUTH-WG] client authentication for implicit grant type

nt Microsoft* in my participation here. I act as a lone developer. I apologize for any confusion. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre On Tue, Apr 12, 2011 at 3:25 PM, Skylar Woodward wrot

Re: [OAUTH-WG] client authentication for implicit grant type

Thanks, Eran. Will the security considerations section discuss this and recommend that auth servers warn the users of the potential phishing attack? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallenty

[OAUTH-WG] client authentication for implicit grant type

Please, will someone either address my concerns (tell me where I'm wrong) or remove that parameter from this grant type? Thanks for your time. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

[OAUTH-WG] Confusing wording in section 2.1

a trait of the authorization endpoint. Am I missing something here, or is this perhaps a misprint? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre We're hiring! My team at

Re: [OAUTH-WG] User-Agent flow and refresh tokens

on the client machine. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre On Wed, Sep 15, 2010 at 3:25 PM, Marius Scurtescu wrote: > I don't see why would you use the user-agent flow with

Re: [OAUTH-WG] resource server id needed?

this were an issue, perhaps you can apply a namespace-like prefix to each scope substring: rs1:photo:read rs2:photo:read Which would serve a similar purpose. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G.

[OAUTH-WG] Section 2.1 Client Password Credentials missing normative form

when it appears in the HTTP Basic authorization header since there is no discussion of it. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre ___ OAuth mai

Re: [OAUTH-WG] issuing new refresh tokens

On Tue, Jul 13, 2010 at 2:59 PM, Brian Eaton wrote: > the question is what happens if both the > signing key and the token database get compromised. > > Now that I think of it, you may have issues if the signing key alone > is compromised. It depends how much other entropy you've added to the >

Re: [OAUTH-WG] issuing new refresh tokens

On Tue, Jul 13, 2010 at 1:56 PM, Brian Eaton wrote: > On Tue, Jul 13, 2010 at 1:46 PM, Andrew Arnott > wrote: > > Ah, got it. Yes, we're on the same page. > > I happen to store the authorization tuple (mentioned in another thread) > > rather than the refresh token

Re: [OAUTH-WG] issuing new refresh tokens

On Tue, Jul 13, 2010 at 1:37 PM, Brian Eaton wrote: > On Tue, Jul 13, 2010 at 1:10 PM, Andrew Arnott > wrote: > >> I'm pretty sure anyone issuing cryptographic refresh tokens is crazy, > >> these pretty much have to be backed by server-side state or there is &

Re: [OAUTH-WG] issuing new refresh tokens

On Mon, Jul 12, 2010 at 10:36 PM, Brian Eaton wrote: > Draft 10 has the following sentence in section 4.1.4: > http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-4.1.4 > > "The authorization server MAY issue a new refresh token." > > That carries a surprising amount of baggage. I suggest

Re: [OAUTH-WG] Basic questions about using the HTTP Authorization header

header? Thanks. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre On Sat, Jun 26, 2010 at 9:42 AM, William Mills wrote: > I don't remember where I found it before, but OWS is Optional Wh

Re: [OAUTH-WG] Security of user agent clients (WAS: End user authresponse code-and-token's scope parameter)

in, I know client secrets don't add value when the client is on an uncontrolled machine. Please don't let that technical hurdle stop you from justifying the status quo in draft 9 of the spec). -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the de

Re: [OAUTH-WG] draft 9, section 4.3.1 missing error code for invalid user credentials

No issue. I didn't consider invalid-grant, but reading it more carefully I should have. Yes, the distinction I was looking for is there. Thanks. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallen

Re: [OAUTH-WG] draft 9, section 4.3.1 missing error code for invalid user credentials

their credentials. Otherwise it leads to user frustration that the client keeps putting up a reprompt for creds when it will never end up working. So from a client perspective it seems like an important distinction. no? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defe

Re: [OAUTH-WG] Security of user agent clients (WAS: End user auth response code-and-token's scope parameter)

en, in the HTTP request at the resource server in order to be considered valid. That should defeat sending the access token away. But other evil things can be done with a illegitimately obtained access token that this wouldn't prevent. -- Andrew Arnott "I [may] not agree with what you h

[OAUTH-WG] Draft 9, Section 2 vs. Section 4.1

io. Am I correct in this? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] draft 9, section 4.3.1 missing error code for invalid user credentials

I see an invalid-client-credentials error code, but for the basic-credentials grant type, it seems there should be a specific error code to indicate the resource owner's basic creds are invalid, as opposed to the client's credentials being invalid. -- Andrew Arnott "I [may] not

[OAUTH-WG] Draft 9, Section 4.1.1 missing several parameters

Section 4.1.1, which deals with requesting an access token using an authorization code, doesn't list the client_id and client_secret parameters at all, yet mentions verifying them in paragraph form, and they are included in the example. -- Andrew Arnott "I [may] not agree with what y

Re: [OAUTH-WG] Security of user agent clients (WAS: End user auth response code-and-token's scope parameter)

play to the user the client being authorized or the list of previously authorized clients. But again, that's totally meaningless if not verified. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tall

Re: [OAUTH-WG] Security of user agent clients (WAS: End user auth response code-and-token's scope parameter)

On Fri, Jul 2, 2010 at 9:12 PM, Eran Hammer-Lahav wrote: > You are putting too much weight on the value of redirection URI > registration. Since the same problem exists between the user-agent script > and the server-side component used in the user-agent profile, anyone can > imitate that flow. In

Re: [OAUTH-WG] Security of user agent clients (WAS: End user auth response code-and-token's scope parameter)

ss severe anyway. But the web-based one must be solved, and this is a way to solve it IMO. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre On Fri, Jul 2, 2010 at 2:13 PM, Eran Hammer-Lahav wrote:

[OAUTH-WG] Security of user agent clients (WAS: End user auth response code-and-token's scope parameter)

something? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre On Fri, Jul 2, 2010 at 10:02 AM, Eran Hammer-Lahav wrote: > At the end of the day, there isn’t much you can do about user-agent > clien

Re: [OAUTH-WG] End user auth response code-and-token's scope parameter

ther mitigation is that implicit re-issuing of an access token to a previously authorized client should be banned without a registered redirect_uri (although this only reduces the risk, as the user is still presented with the wrong client name). Thoughts? -- Andrew Arnott "I [may] not agree w

[OAUTH-WG] End user auth response code-and-token's scope parameter

ther the full scope it requested was actually granted. Was there an advantage to including the scope only in the #fragment, or was this just an oversight? Thanks. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your righ

[OAUTH-WG] Basic questions about using the HTTP Authorization header

sure where the best place is to look this up in. Thanks. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Clarification on whether arguments can contain empty values

, but it might help other implementors who come along next year to get it right the first time if they're reminded in the spec that parameter values may be empty. At least it would have helped me a few years ago in the OpenID spec. :) -- Andrew Arnott "I [may] not agree with what you have to say

Re: [OAUTH-WG] On the ease of writing an authorization server

oving the access token secrets was a great move IMO. I wouldn't have liked it a few months ago, but since it was among the more complex areas of the spec, hard to get right, and no one was planning to use it (from the sound of it) moving it to an extension spec makes tons of sense. -- Andrew

[OAUTH-WG] On the ease of writing an authorization server

o implement correctly and confidently. So my $0.02 here is that we try to keep the AS side simple as well where possible. And invite responses from others. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your r

Re: [OAUTH-WG] Assertion flow: please add optional refresh_token in response

Hi Dick, Responses inline. On Tue, Jun 15, 2010 at 7:12 AM, Dick Hardt wrote: > Why can the client app access the AS to get an access token but not the > corporate network to get a new assertion? > The corporate network where the AD lives is behind a firewall, whereas the AS is on the public I

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

Nope. I'm happy to see it dropped. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre On Tue, Jun 15, 2010 at 12:02 AM, Eran Hammer-Lahav wrote: > Since XML was dropped, if you feel stro

Re: [OAUTH-WG] Assertion flow: please add optional refresh_token in response

t credentials can be found in any of multiple places but must only be found in ONE of them). Let me know what you think. If I need to invent my own profile I guess I can do that. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to sa

Re: [OAUTH-WG] Assertion flow: please add optional refresh_token in response

Well it's easy enough for me to just make up a profile that follows rules I set. But since I don't think this need will be unique to myself, would you like me to write up a spec somewhere? (I've never written an IETF spec before) -- Andrew Arnott "I [may] not agree with what

[OAUTH-WG] Clarification on whether arguments can contain empty values

the remote party doesn't have to do anything but imitate back anyway. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre ___ OAuth mailing list

[OAUTH-WG] Assertion flow: please add optional refresh_token in response

h an *assertion* parameter but using Kerberos (I assume) as part of the HTTP protocol, so perhaps the spec for the assertion flow can specifically allow for assertions to be carried as part of the transport? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend t

Re: [OAUTH-WG] Draft -07 (major rewrite)

verification code as well as an access token? It's unclear what that's for or how that's used. I suggest the spec break the two flows back up to make it easier to parse what message shapes exist. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defen

Re: [OAUTH-WG] Draft -07 (major rewrite)

help differentiate those. Yes, the new flows could include a type parameter while the originals did not, but then a token endpoint not prepared for the unexpected flow would mistake the new flow for the old one. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to

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

Hi Thomas, Some responses inline... On Thu, Jun 10, 2010 at 1:27 PM, Thomas Hardjono wrote: > > > The issue_date enables to scenarios: expiring tokens and token > revocation. > > > Here's how, for each scenario: > > > > > > Obviously to know if a token has expired you need to know when it was >

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

Thanks Marius. I've answered your question below. On Wed, Jun 9, 2010 at 9:35 AM, Marius Scurtescu wrote: > > I've always considered an authorization as a tuple of > > client_id,user,scope,issue_date. If an authorization has been approved, > and > > another request for authorization for a subse

[OAUTH-WG] DotNetOpenAuth preview with OAuth 2.0 support available

other flows are partly there, but not yet functional. I'd also be interested in hearing what you're most interested in seeing support for in the short-term that isn't listed above. Although I'm trying to only implement those areas of the spec least likely to change before it&#x

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

tuple, then that would be the mitigation I guess. But we could avoid extra user prompts if we just forced clients to register their redirect_url's in order to be enabled for user agent flows, thus protecting the user from bad clients sending in evil redirect_urls in order to steal access tokens.

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

t's the secret that accompany the follow-up request for an access token that prevent the security problem in the other flows. > > On Sat, Jun 5, 2010 at 12:49 AM, Andrew Arnott > wrote: > > The user agent flow indicates that the redirect_uri SHOULD be > preregistered > > with

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

, *since that doesn't tell you the public keys to use. Including the public keys in the token itself will significantly increase the size of the token, and assumes again that the RS knows how to pull it out in advance of decoding it. Chicken-and-egg problem. -- Andrew Arnott "I [may]

[OAUTH-WG] Username and Password flow: no captcha?

y. Does anyone from the WG have something they can say on the subject? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre ___ OAuth mailing list OAuth@ie

[OAUTH-WG] Device profile wording

at might also be adjusted for the same reasons. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] User agent flow missing optional scope parameter in response?

sending a new scope value, it will be unable to do so for user-agent clients. Is this intended? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre ___ OAu

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

danger is unique to the user-agent flow because in this flow the client_secret is not required to obtain the access token, whereas it is for other flows. Thoughts? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it.

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

of the parameter as the element name. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre On Fri, Jun 4, 2010 at 6:34 AM, George Fletcher wrote: > I don't know if this is helpful or not..

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

assist the resource server in interpreting the *opaquevalue* part of the token. Feedback? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre ___ OAuth mailing list

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

s slightly more compact which might help small devices. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre On Mon, May 31, 2010 at 9:12 AM, Andrew Arnott wrote: > Where is the definition of how a a

[OAUTH-WG] Definition of XML response format

Where is the definition of how a auth server response in XML format should look? At the least we need an XML namespace and root node name. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S

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

worth for some applications. I don't have a solution to the "avoid sharing client secret with resource servers" problem. Some good points were made I think in this thread about how that would need to be solved. -- Andrew Arnott "I [may] not agree with what you have to say, but I&#

[OAUTH-WG] Should replay of access token request be allowed?

ce. Thanks. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

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

Perhaps we can say that installed client apps can have client secrets after all, by calling the authorization server and asking for a new client_id and client_secret assignment for that particular app-install. Any thoughts on that? -- Andrew Arnott "I [may] not agree with what you have t

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

Hi Dirk, If you eradicated access token secrets in favor of signing with client secrets, how would installed apps, where the client secret is worthless and usually blank, authenticate/sign their own requests? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll def

[OAUTH-WG] Missing quotes?

"timestamp" "=" <"> 1*DIGIT <"> nonce= "nonce" "=" <"> token <"> algorithm= "algorithm" "=" algorithm-name Is this a mistake? -- Andrew Arnott &

[OAUTH-WG] Authorization tokens with signatures on query strings and POST entity

ng the access token does not discuss whether these extra parameters are allowed. Am I missing something, or are tokens with secrets only usable in the Authorization header? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it.&quo

[OAUTH-WG] Assertion flow response missing an expires_in parameter?

In the assertion flow the authorization server issues an access token. In other flows, the access token is accompanied by an expires_in parameter, but not in this one according to the latest draft of the spec. Was this intentional? -- Andrew Arnott "I [may] not agree with what you have t

[OAUTH-WG] Section 7.3 "token_type" vs. section 3.5.3.2 "secret_type"

I think there's a typo in section 7.3 of the latest draft. It mentions a token_type and that's the only place that parameter name appears. But sections that refer to 7.3 have a parameter named secret_type so maybe that's what it should be. -- Andrew Arnott "I [may] not agre