Re: [OAUTH-WG] Last Call: (JWK Thumbprint URI) to Proposed Standard

draft-ietf-oauth-jwk-thumbprint-uri-01 uses labels from the Named Information IANA registry to create URIs from hashes, but then why doesn’t it just use the RFC that created that registry and already defines a way to

Re: [OAUTH-WG] BCP: Client collaborative attacks

>> When using secure elements with specific properties, it is possible to >> counter the Alice & Bob Collusion attack. You don’t just need the Secure Element’s properties (key-pair generated on SE; non-exportable private key; high-entropy key-id generated on SE; conformance cert; special

Re: [OAUTH-WG] BCP: Client collaborative attacks

It is worth mentioning “client collaborative attacks” or “authorization sharing attacks” because OAuth can make them easier (by packaging authority into an access token), compared to the alternative of user’s signing-in to an RS directly. But it is tricky to describe; none of the suggestions

Re: [OAUTH-WG] Towards an RFC Errata to RFC 7662 ?

> Token introspection is an optional feature primarily intended for clients No. The abstract of RFC 7662 (OAuth Introspection) starts: This specification defines a method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of an OAuth 2.0

Re: [OAUTH-WG] Issuers, Discovery Docs & Brands

Wedging support for multiple Authorization Server brands via this "alternative_authorization_endpoints" metadata field is a very kludgy hack. > "alternative_authorization_endpoints": { >"banking": { > "authorization_endpoint": "https://loadsamoney/business/auth;, > "description":

Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

the Client - can be sure of knowing the extent of that information. More End-User control would require a different style of protocol than OAuth, such as self-sovereign identity." -- James Manger From: Denis Sent: Tuesday, 12 May 2020 10:40 PM To: Manger, James ; Vittorio Bertocci Cc: oauth@i

Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

That text is an poor suggestion, Denis. > end-user will usually have no knowledge of the attributes which correspond to > the scope The OAuth model is that the Authorization Server is responsible for informing the end-user about what is going on. That's why they display consent pages showing

Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-13

> the AS could issue the 'sub' value as "urn:anonymous:" > and create a new value with every token that is issued But it those cases it would be better to omit "sub", instead of sending a per-token value (we have "jti" as a per-token id). That at least avoids other parties misinterpreting

Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri

>> It would’ve been nice if JWK could’ve agreed on a URL-based >> addressing format for individual keys within the set, but that ship’s sailed. Using the fragment on a JWKS URL to indicate the key id would be good. Then a single URL by itself can identify a specific key.

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

Syntax glitches in draft-ietf-oauth-pop-key-distribution-06: 1. "exp" and "nbf" values should be numbers, not strings, so must not have quotes [Section 4.2.2. "Client-to-AS Response"] 2. h'11' and b64'...' appear in the JSON examples, but should be "..." strings [Section 4.2.2. "Client-to-AS

Re: [OAUTH-WG] Presenting Seamless Flow at IETF 103

Comments on draft-hevroni-oauth-seamless-flow-01: This draft seems to be about making crypto signatures stateful so you have a better chance of detecting a cloned key as its state will diverge from the original. The link to a seamless OAuth flow seems tangential. A more common way to make

Re: [OAUTH-WG] Non-repudiation for API requests and responses

ACME (Automatic Certificate Management Environment) [draft-ietf-acme-acme] (eg Lets Encrypt CA) is an interesting case. It POSTs JWS objects using the Flattened JSON Serialization with a "url" member in the protected header. It is

[OAUTH-WG] Comments on draft-hardt-oauth-distributed

It is good to see this RESTful authorization server (AS) discovery mechanism. It takes me back to 2010 & 2011 when this idea was also discussed. The "iss" value in the WWW-Authenticate response header should presumably be an AS's real "iss" value, not an AS's token endpoint address. So

Re: [OAUTH-WG] Call for Adoption: Mutual TLS Profiles for OAuth Clients

I support adoption of draft-campbell-oauth-mtls. Now some comments on the doc: 1. [§2.3] The syntax of tls_client_auth_subject_dn is not specified. Perhaps LDAP's "String Representation of Distinguished Names" [RFC4514]? Perhaps a base64url-encoding of a DER-encoded DN? It would actually be

[OAUTH-WG] FW: draft-ietf-oauth-device-flow: url with code

Resending; not sure that OAuth email list is working at the moment. From: Manger, James Sent: Tuesday, 28 February 2017 9:53 AM To: oauth@ietf.org Subject: draft-ietf-oauth-device-flow: url with code How about combining the verification_uri and user_code? The Device Flow provides

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

> You can call me lazy if you want. Some of them are so well known, such as > "password" or "PIN" it didn't seem worthwhile to try to track down a > reference. "password" and "PIN" are so well known, yet curiously they are quite different as "amr" values. "pwd" is merely defined as

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

>Title : OAuth 2.0 Token Exchange: An STS for the REST of Us > https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-05 This spec has some useful functionality, but comes across as a tad conceited. Suggestions: 1. Drop "An STS for the REST of Us" from the title. "STS" is

Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (4697)

I suggest this errata be REJECTED as token types are case-insensitive. Each field in RFC6749 that takes a token type explicitly says the value is case insensitive. 4.2.2. Access Token Response token_type REQUIRED. The type of the token issued as described in Section 7.1.

Re: [OAUTH-WG] Cross Platform Authentication - OAuth 2.0 Device Flow - WWW-Authenticate to advertise OAuth 2.0 support

for it. -- James Manger From: Nat Sakimura [mailto:sakim...@gmail.com] Sent: Sunday, 15 May 2016 1:38 AM To: Manger, James <james.h.man...@team.telstra.com>; Hannes Tschofenig <hannes.tschofe...@gmx.net>; oauth@ietf.org; barr...@ebu.ch Subject: Re: [OAUTH-WG] Cross Platform Au

Re: [OAUTH-WG] Cross Platform Authentication - OAuth 2.0 Device Flow - WWW-Authenticate to advertise OAuth 2.0 support

Hi Michael & OAuth-ers, The EBU Cross Platform Auth spec has defined their own "CPA" scheme for the WWW-Authenticate HTTP response header to advertise OAuth 2.0 capability [section 7.7.1 "Authentication challenge" in https://tech.ebu.ch/docs/tech/tech3366.pdf]. WWW-Authenticate: CPA

Re: [OAUTH-WG] HTTP request signing and repeated query/header keys

Being able to selectively include or exclude individual query string name=value parameters in a signature feels far too dangerous. Always sign them all — with the only exception being the signature itself if transmitted as a query string parameter. Unfortunately we do need to selectively

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

ts seems like a complexity that will quickly get out of hand. Thanks, George On 2/25/16 2:22 AM, Vladimir Dzhuvinov wrote: On 25/02/16 09:02, Manger, James wrote: I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture T

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

> I'm concerned that forcing the AS to know about all RS's endpoints that will > accept it's tokens creates a very brittle deployment architecture The AS is issuing temporary credentials (access_tokens) to clients but doesn’t know where those credentials will work? That’s broken. An AS should

[OAUTH-WG] oauth-meta: turi allows user to mislead app

The OAuth-Meta draft returns the token endpoint (in a "turi" query parameter) when redirecting a user from the authorization endpoint back to an app. The app presumably then POSTs the "code" (also in the redirect) to "turi" to get an access token. However, apps typically send their

Re: [OAUTH-WG] oauth-meta: turi allows user to mislead app

at feel much harder for apps or servers to accidentally misuse insecurely. -- James Manger From: Nat Sakimura [mailto:n-sakim...@nri.co.jp] Sent: Thursday, 28 January 2016 3:02 PM To: Manger, James <james.h.man...@team.telstra.com>; oauth@ietf.org Subject: RE: [OAUTH-WG] oauth-meta: turi allows us

Re: [OAUTH-WG] Call for Adoption: Authentication Method Reference Values

Accepting draft-jones-oauth-amr-values-03 is almost okay as a starting point for work. I would like to see significant changes though: * The "amr_values" parameter should be dropped; it just encourages brittle designs as section 4 "relationship to acr" and section 6 "security considerations"

Re: [OAUTH-WG] implementations of draft-ietf-oauth-proof-of-possession

That value uses strings for expiry and not-before dates so it is not a valid JWT; these dates need to be numbers. 3 of the examples in draft-ietf-oauth-proof-of-possession are similarly invalid ("exp" and "iat"); 1 example gets it right. -- James Manger -Original Message- From:

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-09.txt

Title : Proof Key for Code Exchange by OAuth Public Clients Filename: draft-ietf-oauth-spop-09.txt https://tools.ietf.org/html/draft-ietf-oauth-spop-09 Some nits on this draft: 1. 42 chars. The lower limit of 42 chars for code_verifier: is not mentioned in prose

[OAUTH-WG] Symmetric Proof of Possession for the OAuth Authorization Code Grant: comments

Couple of comments on draft-ietf-oauth-spop-00: The draft defines a nice little mechanism to link two requests: one from app-to-browser-to-server, the other from app-to-server. 1. The spec defines the bearer token version of linking the requests: pick a random value and send it in both

Re: [OAUTH-WG] Proof-Of-Possession Semantics for JSON Web Tokens (JWTs)

http://tools.ietf.org/html/draft-jones-oauth-proof-of-possession-00 A new registry for cnf members is a bit strange. A JWT Claim Set has so far been a flat structure, with metadata such expiry date exp alongside claims such as given_name. This spec starts introducing structure by wrapping

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

the collision-resistance when you combine multiple namespaces (domain names, OIDs, etc). -- James Manger From: Mike Jones [mailto:michael.jo...@microsoft.com] Sent: Tuesday, 4 March 2014 9:22 AM To: Manger, James; oauth@ietf.org WG Subject: RE: [OAUTH-WG] WGLC on JSON Web Token (JWT) Thanks for taking

Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and bearer tokens

” access tokens (whatever that is for this AS) would be even more useful. -- James Manger From: John Bradley [mailto:ve7...@ve7jtb.com] Sent: Thursday, 6 June 2013 7:22 PM To: Tschofenig, Hannes (NSN - FI/Espoo) Cc: ext Tim Bray; Manger, James H; oauth@ietf.org Subject: Re: [OAUTH-WG] draft-ietf

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

Tim Bray wrote: FWIW, I just read the spec through with fresh eyes, and I found the explanation of the workflow in 1.4.2 very useful.   - A developer manually registers and then is able to request “Initial tokens” tokens for a dynamic-app-registration-scope,  - you use that “Initial token”

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

authorized, the development suite collects a token from the token endpoint. That token is the “initial access token”. That would be OAuth 2 for the first part. -- James Manger From: Tim Bray [mailto:twb...@google.com] Sent: Thursday, 6 June 2013 1:23 PM To: Manger, James H Cc: oauth@ietf.org Subject

[OAUTH-WG] draft-ietf-oauth-dyn-reg and bearer tokens

BEARER tokens dominate OAuth 2 deployments today, but OAuth 2 is deliberately extensible to support other sorts of credentials (eg MAC authentication). Why is draft-ietf-oauth-dyn-reg hardwired to only support BEARER tokens? 1.3. “Registration Tokens and Credentials” says: “The Initial

Re: [OAUTH-WG] Registration: Scope Values

Presumably at app registration time any scope specification is really a constraint on the scope values that can be requested in an authorization flow. So ideally registration should accept rules for matching scopes, as opposed to actual scope values. You can try to use scope values as their

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

What is an “internationalized UTF-8 string”? P.S. It would be worth explicitly stating that the # character and RFC5646 language tag are appended *to the field name* (not the value). I assume this is right. -- James Manger From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf

Re: [OAUTH-WG] access tokens refresh tokens of different scopes

Adam, I’ll chime in and say you have a reasonable requirement (getting tokens with different scopes (for different resource servers) efficiently). Over the last few years there have been a number of proposals for OAuth to support this (by allowing an authorization server to return multiple

Re: [OAUTH-WG] Proposed note to RFC Editor

The changes introduced in Draft 29 had unintended consequences on parts of the spec caused by Sec 4.3, 4.4 and 6 referencing Sec 3.2.1 as part of client authentication. this change breaks https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ and

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

Hannes, today I submitted a short document that illustrates the concept of holder-of-the-key for OAuth. Here is the document: https://datatracker.ietf.org/doc/draft-tschofenig-oauth-hotk A different approach would be for the service to issue a private asymmetric key to the client app,

Re: [OAUTH-WG] Nested JWT (was: Re: [jose] typ:JWS)

A nested JWT is one where a JWT is used as the payload of another JWT, for instance, so you can do sign/encrypt/sign. So, first of all, it seems like an abuse of terminology to say JWT within a JWT, unless you really want to create an infinite recursion. It would be better to say a JWT is a

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

Are we so sure the non-english half of the world only use ASCII characters in passwords? Sounds highly unlikely to me. Given that, as you confirmed, UTF-8 doesn't work with Basic and Digest... It can work. It is just underspecified. So things can get messy. draft-reschke-basicauth-enc-05 is a

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

Adam, You are describing OpenID Connect. -- James Manger - Reply message - From: Lewis Adam-CAL022 adam.le...@motorolasolutions.com Date: Sat, Jun 2, 2012 12:00 am Subject: [OAUTH-WG] Inter-domain AS/RS communication (revisited) To: oauth@ietf.org oauth@ietf.org Hi all, I’ve asked

Re: [OAUTH-WG] OAuth Bearer: Response to an unauthenticated request

Bill, A WWW-Authenticate response header that identifies an authorization server (AS) would be a great hypermedia-driven solution. It tells the client app which AS a service trusts. The client app can then get a token. ... Yeah, unfortunately the WWW-Authenticate solution advertising an AS

Re: [OAUTH-WG] OAuth Bearer: Response to an unauthenticated request

I’m not sure it is any worse than a resource returning WWW-Authenticate: BASIC ... to trigger the password being sent?). -- James Manger From: William Mills [mailto:wmi...@yahoo-inc.com] Sent: Thursday, 17 May 2012 12:29 AM To: Manger, James H; oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Bearer

Re: [OAUTH-WG] OAuth Bearer: Response to an unauthenticated request

Sergey, A hypermedia-driven (RESTful) API should be able to use OAuth. Unfortunately, OAuth does not have a RESTful design. Most APIs require client apps (not just the user) to be pre-registered with the service. That seems to have made hypermedia-driven design less important - if a client

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

+1 -- James Manger - Reply message -From: Mike Jones michael.jo...@microsoft.com 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 paul.mad...@gmail.com, Brian Campbell bcampb...@pingidentity.com Cc:

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

Brian, On casual reading of The OAuth 2.0 Authorization Protocol: Bearer Tokens* I've encountered several people (including myself) who have made the assumption that the name b64token implies that some kind of base64 encoding/decoding on the access token is taking place between the client

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

Eran, a couple of comments on the new MAC spec: The example (§1.1) does not seem to be correct. That is, I calculate mac=6T3zZzy2Emppni6bzL7kdRxUWL4= instead of the given value. The example in §3.2.1 has a typo. It says using timestamp 264095:7d8f3e4a, but should say using timestamp 264095.

Re: [OAUTH-WG] Webex for OAUTH-WG meeting at IETF82 Taipei

I would like to join by webex. -- James Manger -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Thomas Hardjono Sent: Friday, 4 November 2011 6:33 AM To: oauth (oauth@ietf.org) Cc: barryle...@computer.org Subject: [OAUTH-WG] Webex for OAUTH-WG

Re: [OAUTH-WG] AD review of draft-ietf-oauth-bearer-13

5) Section 3 ABNF allows realm=foo;realm=bar;scope=baz;error=123 is that ok? Is processing clear for all cases? I don't think it is. The ABNF does not allow that. It requires commas as separators, not semi-colons. It requires double quotes around values. The only possible ambiguity in this

[OAUTH-WG] draft-ietf-oauth-v2-bearer-12: ABNF nits

The error-desc value should just be quoted-string. The current ABNF implies you can include raw (unescaped) and \ characters in the value (as they are chars in VCHAR) - but that breaks parsing. If the intention was not to allow senders to use escapes then error-desc-char needs to be %x20-%x21 /

Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments

One possible syntax is: Bearer access_token=xyz_-123,more_info=pdq Ultimately though, the format of the bearer token is outside of the scope of the spec, and up to the participants to determine, including whether to use b64token syntax or params syntax. It is great to see an example

Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments

2. The ABNF for credentials does not comply with RFC 2617 HTTP Authentication. So where are we on this? Any progress? Some progress. draft-ietf-oauth-v2-bearer-09 defines the “Authorization: Bearer ...” request header to match draft-ietf-httpbis-p7-auth. It uses b64token for the access

Re: [OAUTH-WG] Possible alternative resolution to issue 26

You can't replace quoted-string. A recipient will have to be able to parse multiple challenges in a single header field value. To do so, it has to understand the syntax of params using double quotes. It can't special-case the parsing based on what part of the set of challenges it

Re: [OAUTH-WG] Possible alternative resolution to issue 26

Option 3 has a serious flaw in that it requires escaping the \ in \u, because it is the escape character in quoted-string. I think it's certain that people will be confused by that, and interop problems will happen (unless you have a strong test suite). No, the \ in \u would not be

Re: [OAUTH-WG] Possible alternative resolution to issue 26

The best solution is to drop the scope field from the WWW-Authenticate: Bearer ... response header. scope is relevant to an OAuth2-core flow, not to presenting a bearer token. scope could make sense in a WWW-Authenticate: OAuth2 ... response header as long as other necessary details such as an

Re: [OAUTH-WG] Proposed resolution for issue 26

I'll have another go trying to explain the problem I see with the scope parameter in the Bearer spec. Consider a French social network that decides to offer an API using OAuth2. It chooses 3 scope values for parts of the API related to family, friends, and business colleagues: * famille * ami

Re: [OAUTH-WG] Proposed resolution for issue 26

From: Mike Jones Issue #26 http://trac.tools.ietf.org/wg/oauth/trac/ticket/26 asks whether the semantics of scope strings should be changed to require that the % character be interpreted as introducing a percent-encoded character that follows.  My proposed resolution is that %-encoding

Re: [OAUTH-WG] Bearer token credentials syntax

-1 credentials = Bearer 1*SP b64token would make sense. credentials = Bearer 1*SP ( b64token / #auth-param ) does not make sense as the spec doesn't define a way to carry the bearer token in the #auth-param choice. -- James Manger From: oauth-boun...@ietf.org

Re: [OAUTH-WG] problem statement

A strange aspects of this thread is that the current draft already talks about exactly this issue: draft-ietf-oauth-v2-21 section 9 Native Applications ...Native applications can invoke an external user-agent or embed a user-agent within the application ... Embedded user-agents pose a

Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments

ABNF for challenge and credentials that supports the base64-blobs used by BASIC and NTLM. It does not allow what BEARER tries to do. -- James Manger From: Manger, James H james.h.man...@team.telstra.com To: oauth@ietf.org oauth@ietf.org Sent: Thursday, July 28

[OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments

My working group last call comments on draft-ietf-oauth-v2-bearer-08.txt: 1. Mentioning that this is an HTTP authentication mechanism in the title and/or abstract would be useful to the wider IETF ( beyond) audience. Title: The BEARER HTTP authentication mechanism for use with OAuth 2

Re: [OAUTH-WG] Example tokens

Are the tokens used in the examples long enough? I don't want the examples to demonstrate poor choice of byte count. No. I found the following example values in draft 16. Client secret: gX1fBat3bV (10 chars, 60 bits) Code: i1WsRn1uB1 (10 chars, 60

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

If we're changing the bearer token's name, are we going to change the parameter name inside of MAC as well? At the moment, it's id, which I've always found an odd naming choice. I would argue for consistency across the three main documents. OAuth2 should be consistent with the

Re: [OAUTH-WG] Redirection URI and Implicit grant

It seems like an authorization server receiving a request with an unregistered redirect_uri of https://example.org/ can tell the user: Permission will be passed to your browser then onto *example.org* An authorization server receiving a request with a registered redirect_uri of

[OAUTH-WG] issuing multiple tokens

Torsten Lodderstedt needs to issue multiple tokens; Igor Faynberg said +1 to that; John Bradley identified that OpenID Connect needs to request multiple tokens; Eran Hammer-Lahav even mentioned a no-token flow as something that could make sense; ... Issuing 0, 1 or more tokens looks like an

[OAUTH-WG] FW: MAC: Cookie name or value as MAC key id

There have been suggestions that the MAC calculation could/should cover the key id. In that situation it is even more crucial that the id field isn't just a name referring to the real value elsewhere - as then the security changes based on the syntax used to issue the credentials. What

Re: [OAUTH-WG] FW: MAC: Cookie name or value as MAC key id

Perhaps omitting the id parameter from the Authorization header would be an even better approach [when a cookie provides the key id] Yeah, I've often wondered whether we should remove the id parameter from the Authorization header. My understanding is that it plays some important role in

Re: [OAUTH-WG] FW: MAC: Cookie name or value as MAC key id

How does the server know if a particular request with a Authorization: MAC ... header is using credentials from OAuth 2.0 or from Set-Cookie? This should be pretty easy to resolve with a common-sense deployment and key identifiers. You are right, Eran. Though putting a cookie-name in a key

[OAUTH-WG] MAC: Cookie name or value as MAC key id

A comment on the MAC draft [draft-ietf-oauth-v2-http-mac-00]: When MAC credentials are issued with a Set-Cookie response header [section 6] the spec says to use the cookie's name as the MAC key identifier (eg id=SID). It would make more sense to use the cookie's value (eg

Re: [OAUTH-WG] MAC: Cookie name or value as MAC key id

This is a bit hacky, too hacky. Wouldn't it be better for a client that recognizes a special MAC cookie to use it to construct Authorization headers and omit it from Cookie headers? Nope. Sending the value in the Cookie header is important to help servers implement this scheme without

Re: [OAUTH-WG] I-D Action:draft-oauth-dyn-reg-v1-02.txt

Comments on the OAuth Dynamic Client Registration Protocol [draft-oauth-dyn-reg-v1-02]: I found it hard to gleam from this draft where any trust in the client information being registered comes from. Sources could be: self-asserted; PKI with well-known roots; or DNS. OpenID and WebID are two

Re: [OAUTH-WG] Revised Section 3

I'm certainly in favour of excluding client auth from OAuth. Dropping section 3 and just having a paragraph like the following would be preferable (with no capitalized keywords): In many cases an authorization server will require client authentication for requests to a token endpoint.

Re: [OAUTH-WG] OAuth2 scheme

I will have a go writing an I-D defining an OAuth2 WWW-Auth response header... though it will not be for at least a fortnight :-( -- James Manger From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Saturday, 9 April 2011 1:56 PM To: Manger, James H; OAuth WG Subject: RE: OAuth2

Re: [OAUTH-WG] OAuth2 scheme

Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Friday, 8 April 2011 12:04 PM To: William J. Mills; Manger, James H; OAuth WG Subject: RE: [OAUTH-WG] OAuth2 scheme I agree that Link headers are much better fit for relaying discovery information than a half HTTP authentication scheme. Overall, I

Re: [OAUTH-WG] OAuth2 scheme

[Sorry, I didn't see this email before I sent my last one] Chairs - I would like to ask that you declare all discovery requirements and use cases out of scope for v2 and the working group at this point. --- As for the error code registry and the request Mike posted, I do not think

Re: [OAUTH-WG] draft-15 editorials

' might create, thus the air quotes paul From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Manger, James H Sent: Thursday, 17 March 2011 1:40 PM To: OAuth WG Subject: [OAUTH-WG] OAuth2 abstract Comments on draft-ietf-oauth-v2-13: 1. Abstract The 1-line

[OAUTH-WG] draft-15 editorials

A few, mainly editorial, points on the latest OAuth 2.0 core draft [draft-ietf-oauth-v2-15]: Abstract: Currently it is: The OAuth 2.0 authorization protocol enables granting third-party applications limited access to HTTP service on behalf of an end-user by orchestrating an

[OAUTH-WG] Comments on draft-lodderstedt-oauth-security

A few comments on parts of the OAuth 2.0 Threat Model and Security Considerations: * [2.1. Scope] Resource server URLs are static and well-known at development time is a very strong assumption. It eliminates much of the value of having an OAuth standard (reducing it to aiding some

Re: [OAUTH-WG] Indicating origin of OAuth credentials to combat login CSRF

OAuth issues security tokens without indicating where they can be safely used. While that fatal flaw remains, it is pointless to specify the use of the Origin header. I don't think anything should be in the base as the different token profiles can stipulate the audience. But they

Re: [OAUTH-WG] Authorization grant abstraction

Justin, The important thing is the logical distinction between place where the client goes and place where the client sends an end user, and that those don't get folded into each other. I certainly don't want to fold those two together. The issue is whether the spec should fold together all

Re: [OAUTH-WG] Indicating origin of OAuth credentials to combat login CSRF

Q. Should an OAuth client app list the authorization server in the Origin header of requests to resource servers? Was there any conclusion? My conclusion is that the Origin request header is the right place to list the OAuth authorization server to combat login CSRF attacks against

[OAUTH-WG] Authorization grant abstraction

OAuth2 now defines a single URI - the token endpoint - that has to be capable of processing: * State from a user approval interaction (encoded into a 'code' parameter); * User passwords; * Client app credentials; * SAML tokens; * JSON Web Tokens

Re: [OAUTH-WG] Method of validating client id client secret for authenticated requests?

Steve, I'm evaluating whether OAuth 2 draft 13 w/ MAC authentication will be suitable for my situation. ... I want to ensure that a user cannot use their own valid access token to make API calls from non-approved clients. ... I'm aware that determined users could extract the client ID

Re: [OAUTH-WG] OAuth Bearer Token draft

Justin Richer said: Since all formats are optional,... No they aren't. draft-ietf-oauth-v2-bearer-03 says Resource servers MUST accept [the Authorization header], and MAY support [body query parameters] -- James Manger ___ OAuth mailing list

[OAUTH-WG] Comments on draft-ietf-oauth-v2-bearer-03

Comments on the bearer token spec: 1. There is a whole lot of text about OAuth2 get-a-token parts that isn't necessary in the bearer token spec. A bit of context can be useful to a reader, but in this case it brings too much of the complexity of the get-a-token flows into what should be a

Re: [OAUTH-WG] Indicating origin of OAuth credentials to combat login CSRF

Francisco, A client that follows HTTP redirects (or Link: header or any other variety of hypertext) might get directed to an 2nd service while still using the token from the 1st service. But why would a legitimate authorization server redirect the client to an attacker's server? It

Re: [OAUTH-WG] Indicating origin of OAuth credentials to combat login CSRF

...@pomcor.com] Sent: Tuesday, 1 March 2011 4:17 PM To: OAuth Mailing List; Manger, James H Cc: Karen P. Lewison Subject: RE: [OAUTH-WG] Indicating origin of OAuth credentials to combat login CSRF Hi James, I think I got it now. Thanks for explaining it so patiently. The attack is only possible

Re: [OAUTH-WG] Indicating origin of OAuth credentials to combat login CSRF

Hi Francisco, Q. Should an OAuth client app list the authorization server in the Origin header of requests to resource servers? In OAuth (delegation) flows a server dynamically issues credentials (such as a bearer token) to a client app to use in subsequent HTTP requests to other

[OAUTH-WG] Indicating origin of OAuth credentials to combat login CSRF

Q. Should an OAuth client app list the authorization server in the Origin header of requests to resource servers? In OAuth (delegation) flows a server dynamically issues credentials (such as a bearer token) to a client app to use in subsequent HTTP requests to other servers. To combat login

Re: [OAUTH-WG] Bearer token scheme name - new vote deadline Sat, 2/12

The previous poll already had these two options, with the non-OAuth-specific name getting 14 votes to 1 vote for an OAuth prefix. 1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC) ... 3. Name prefix (e.g. oauth2_bearer) I vote for 2 Bearer. -- James Manger From:

Re: [OAUTH-WG] Discovery RE: Bearer token type and scheme name (deadline: 2/10)

I see 4 suggestions for discovery (getting details about the OAuth endpoints etc to client apps): 1. Include it as extra params when advertising authentication mechanisms. WWW-Authenticate: MAC realm=..., any MAC-specific params, auth_url=http... I don't like this as it changes WWW-Auth

Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

Dirk said: FWIW, I agree with Brian - it [the Bearer scheme] should say OAuth somewhere, because it's an OAuth token. OAuth can deliver any variety of bearer token: SAML, JWT, SWT, opaque id, anything else. Conversely, any of these tokens can come from a variety of sources: a

[OAUTH-WG] WWW-Auth. OAuth scheme (was RE: Bearer token type and scheme name (deadline: 2/10))

Phil Hunt said: The only other issue would be determining whether the token is obtained via an OAuth profile or via some default profile. That could be handled with something like: WWW-Authenticate: Basic realm=somerealm WWW-Authenticate: MAC realm=somerealm WWW-Authenticate: OAuth

Re: [OAUTH-WG] more comments on draft-hammer-oauth-v2-mac-token-02 -- algorithm param

Eran, 13. The MAC algorithm should be explicitly indicated in the request, instead of being implied by the access-token/id. I suggest including an algorithm parameter in the Authorization request header. I also suggest including an algorithms parameter in the WWW-Authenticate response header

Re: [OAUTH-WG] more comments on draft-hammer-oauth-v2-mac-token-02 -- encoding of secret

Eran, 16. OAuth2 can provide a secret as a Unicode string. MAC algorithms such as HMAC use a key that is a byte array. Section 2 of the MAC spec says 'secret' can only include printable ASCII chars (except and /). This is not quite right. The MAC scheme should expect 'secret' to be a byte

Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

+1 for #1 #2 is awful; #3 is unnecessary; #4 OAuth2 just has less meaning than, say, Bearer. #1 offers the cleanest separation between using-a-token to authenticated a request and a delegation flow to authorize a client which is likely to be helpful for lots of people now and in the future

Re: [OAUTH-WG] more comments on draft-hammer-oauth-v2-mac-token-02

14. Explicitly state in section 3.3.2 (and 3.3.3) that SHA-1 (and SHA-256) are used to calculate the body hash when using the hmac-sha-1 (and hmac-sha- 256) algorithm. Why isn't 3.2 enough? That's where body hash is discussed. 3.2 says the body hash algorithm is determined by the access

Re: [OAUTH-WG] OAuth MAC token type draft

- Authentication schemes You propose to use the authentication scheme name OAuth2 for the WWW-Authenticate header but another scheme name MAC for the authorization header. I've never seen such an asymmetric approach before. Don't you think people get confused about that? This was proposed

  1   2   3   >