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

2022-04-26 Thread Manger, James
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

2020-10-28 Thread Manger, James
>> 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

2020-10-26 Thread Manger, James
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 ?

2020-09-02 Thread Manger, James
> 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

2020-06-04 Thread Manger, James
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"

2020-05-12 Thread Manger, James
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"

2020-05-12 Thread Manger, James
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

2020-04-15 Thread Manger, James
> 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

2020-01-28 Thread Manger, James
>> 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

2019-03-11 Thread Manger, James
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

2018-09-17 Thread Manger, James
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

2018-09-03 Thread Manger, James
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

2017-11-14 Thread Manger, James
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

2017-04-20 Thread Manger, James
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

2017-02-28 Thread Manger, James
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)

2017-02-01 Thread Manger, James
> 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

2016-07-10 Thread Manger, James
>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)

2016-05-19 Thread Manger, James
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

2016-05-15 Thread Manger, James
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

2016-05-12 Thread Manger, James
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

2016-02-28 Thread Manger, James
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

2016-02-25 Thread Manger, James
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

2016-02-24 Thread Manger, James
> 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

2016-01-27 Thread Manger, James
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

2016-01-27 Thread Manger, James
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

2016-01-19 Thread Manger, James
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

2015-12-13 Thread Manger, James
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

2015-02-04 Thread Manger, James
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

2014-08-28 Thread Manger, James
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)

2014-04-01 Thread Manger, James
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)

2014-03-11 Thread Manger, James
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

2013-06-06 Thread Manger, James H
” 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

2013-06-05 Thread Manger, James H
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

2013-06-05 Thread Manger, James H
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

2013-06-05 Thread Manger, James H
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

2013-04-14 Thread Manger, James H
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

2013-03-21 Thread Manger, James H
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

2012-10-31 Thread Manger, James H
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

2012-07-26 Thread Manger, James H
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

2012-07-09 Thread Manger, James H
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)

2012-07-07 Thread Manger, James H
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

2012-06-11 Thread Manger, James H
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)

2012-06-01 Thread Manger, James H
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

2012-05-16 Thread Manger, James H
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

2012-05-16 Thread Manger, James H
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

2012-05-15 Thread Manger, James H
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

2012-03-11 Thread Manger, James H
+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

2012-03-05 Thread Manger, James H
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

2012-02-08 Thread Manger, James H
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

2011-11-03 Thread Manger, James H
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

2011-11-02 Thread Manger, James H
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

2011-10-27 Thread Manger, James H
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

2011-10-12 Thread Manger, James H
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

2011-10-11 Thread Manger, James H
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

2011-10-09 Thread Manger, James H
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

2011-10-07 Thread Manger, James H
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

2011-10-02 Thread Manger, James H
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

2011-09-27 Thread Manger, James H
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

2011-09-24 Thread Manger, James H
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

2011-09-24 Thread Manger, James H
-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

2011-09-06 Thread Manger, James H
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

2011-08-31 Thread Manger, James H
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

2011-07-28 Thread Manger, James H
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

2011-07-06 Thread Manger, James H
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

2011-06-16 Thread Manger, James H
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

2011-06-15 Thread Manger, James H
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

2011-06-15 Thread Manger, James H
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

2011-06-14 Thread Manger, James H
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

2011-06-14 Thread Manger, James H
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

2011-06-14 Thread Manger, James H
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

2011-06-13 Thread Manger, James H
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

2011-06-13 Thread Manger, James H
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

2011-05-03 Thread Manger, James H
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

2011-04-14 Thread Manger, James H
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

2011-04-12 Thread Manger, James H
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

2011-04-08 Thread Manger, James H
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

2011-04-08 Thread Manger, James H
[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

2011-04-06 Thread Manger, James H
' 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

2011-04-05 Thread Manger, James H
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

2011-03-29 Thread Manger, James H
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

2011-03-29 Thread Manger, James H
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

2011-03-28 Thread Manger, James H
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

2011-03-27 Thread Manger, James H
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

2011-03-25 Thread Manger, James H
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?

2011-03-16 Thread Manger, James H
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

2011-03-10 Thread Manger, James H
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

2011-03-02 Thread Manger, James H
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

2011-02-28 Thread Manger, James H
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

2011-02-28 Thread Manger, James H
...@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

2011-02-27 Thread Manger, James H
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

2011-02-24 Thread Manger, James H
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

2011-02-08 Thread Manger, James H
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)

2011-02-07 Thread Manger, James H
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)

2011-02-06 Thread Manger, James H
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))

2011-02-06 Thread Manger, James H
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

2011-02-06 Thread Manger, James H
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

2011-02-06 Thread Manger, James H
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)

2011-02-03 Thread Manger, James H
+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

2011-02-03 Thread Manger, James H
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

2011-01-10 Thread Manger, James H
- 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   >