Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-revocation-09: (with DISCUSS and COMMENT)

Hi Torsten, Sorry for the delay on this. I've cleared on D2. Focusing this response on point D1: --**--**-- >> DISCUSS: >> --**--** >> -- >> >> D1. The mandate for T

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-revocation-09: (with DISCUSS and COMMENT)

gt; > regards, > Torsten. > > Am 12.07.2013 20:43, schrieb Richard Barnes: > > Hi Torsten, > > Sorry for the delay on this. I've cleared on D2. Focusing this > response on point D1: > > > -

[OAUTH-WG] Plaintext JWT bug

It has come to my attention that JWT is using "alg":"none" to create "Plaintext JWTs". Some of us in JOSE believe that this "alg" value should be removed, because of a risk of downgrade attacks. In order to do that, a suggested revision to JWT is below. To summarize: -- Plaintext JWTs are not JW

Re: [OAUTH-WG] Plaintext JWT bug

-- Mike > > ** ** > > *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf > Of *Richard Barnes > *Sent:* Thursday, August 01, 2013 5:08 AM > *To:* oauth@ietf.org WG > *Subject:* [OAUTH-WG] Plaint

Re: [OAUTH-WG] Plaintext JWT bug

that’s an > application bug – not a spec bug. > > ** ** > > -- Mike > > ** ** > > *From:* Richard Barnes [mailto:r...@ipv.sx] > *Sent:* Thursday, August 01, 2013 5:24 AM > *To:* Mike Jones > *Cc:* oauth@ietf.

Re: [OAUTH-WG] [jose] alternative term to "plaintext" for the "none" alg (was Re: Review of: draft-ietf-oauth-json-web-token)

I will re-iterate here my strong preference that an "unsecured" or "plaintext" JWS object be syntactically distinct from a real JWS object. E.g. by having two dot-separated components instead of three. Beyond that, seems like just shuffling deck chairs. On Mon, Sep 8, 2014 at 12:10 PM, Brian Camp

[OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT)

Richard Barnes has entered the following ballot position for draft-ietf-oauth-json-web-token-27: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT)

On Mon, Oct 6, 2014 at 3:54 AM, Mike Jones wrote: > Thanks for your review, Richard. My responses are inline below... > > > -Original Message- > > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Richard Barnes > > Sent: Wednesday, October 01, 2014

[OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

Richard Barnes has entered the following ballot position for draft-ietf-oauth-assertions-17: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to

[OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-saml2-bearer-21: (with DISCUSS)

Richard Barnes has entered the following ballot position for draft-ietf-oauth-saml2-bearer-21: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to

[OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-jwt-bearer-10: (with DISCUSS and COMMENT)

Richard Barnes has entered the following ballot position for draft-ietf-oauth-jwt-bearer-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

auth-boun...@ietf.org] On Behalf Of Richard Barnes > > Sent: Wednesday, October 15, 2014 8:48 PM > > To: The IESG > > Cc: draft-ietf-oauth-asserti...@tools.ietf.org; > oauth-cha...@tools.ietf.org; > > oauth@ietf.org > > Subject: [OAUTH-WG] Richard Barnes' Disc

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

t; www.independentid.com > phil.h...@oracle.com > > > > On Oct 16, 2014, at 8:43 AM, Brian Campbell > wrote: > > Thanks for your review and feedback, Richard. Replies are inline below... > > On Wed, Oct 15, 2014 at 9:47 PM, Richard Barnes wrote: > >> Richard

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-jwt-bearer-10: (with DISCUSS and COMMENT)

On Thu, Oct 16, 2014 at 1:44 PM, Brian Campbell wrote: > Thanks for your review and feedback on this one too, Richard. Replies are > inline below... > > On Wed, Oct 15, 2014 at 10:01 PM, Richard Barnes wrote: > >> Richard Barnes has entered the following ballot position fo

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-saml2-bearer-21: (with DISCUSS)

That's what you get for duplicating all the text :) On Thu, Oct 16, 2014 at 2:00 PM, Brian Campbell wrote: > Basically the same response to the basically same question as from > http://www.ietf.org/mail-archive/web/oauth/current/msg13608.html > > On Wed, Oct 15, 2014 at 9:56 P

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

On Thu, Oct 16, 2014 at 3:20 PM, Richard Barnes wrote: > You guys are all arguing that having an Audience can be useful. I don't > disagree. I disagree that it should be REQUIRED in all cases. > > The Google vulnerability that Brian raised was an interesting read, but as >

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

On Fri, Oct 17, 2014 at 10:32 AM, John Bradley wrote: > I think this part of sec 3 of assertions states that: > > The protocol parameters and processing rules defined in this document >are intended to support a client presenting a bearer assertion to an >authorization server. The use of

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

un...@ietf.org] *On Behalf Of *Phil Hunt > *Sent:* Friday, October 17, 2014 9:50 AM > *To:* John Bradley > *Cc:* draft-ietf-oauth-asserti...@tools.ietf.org; Richard Barnes; > oauth-cha...@tools.ietf.org; The IESG; oauth > *Subject:* Re: [OAUTH-WG] Richard Barnes' Discuss on > d

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-jwt-bearer-10: (with DISCUSS and COMMENT)

On Fri, Oct 17, 2014 at 9:27 AM, Brian Campbell wrote: > > > On Thu, Oct 16, 2014 at 4:32 PM, Richard Barnes wrote: > >> >> >> On Thu, Oct 16, 2014 at 1:44 PM, Brian Campbell < >> bcampb...@pingidentity.com> wrote: >> >>> Thanks for y

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT)

Thanks again, > -- Mike > > > -Original Message- > > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones > > Sent: Saturday, October 11, 2014 12:54 PM > > To: Richard Barnes > > Cc: draft-ietf-oauth-json-web-to...@tools.ietf.org; oauth- >

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

rian Campbell [mailto:bcampb...@pingidentity.com] > *Sent:* Friday, October 17, 2014 8:23 AM > *To:* Richard Barnes > *Cc:* John Bradley; draft-ietf-oauth-asserti...@tools.ietf.org; Pete > Resnick; oauth; The IESG; oauth-cha...@tools.ietf.org > *Subject:* Re: [OAUTH-WG] Richard Barnes'

Re: [OAUTH-WG] What error codes do you need?

In case it's helpful, BCP 56 / RFC 3205 provides recommendations for using HTTP as a substrate for other protocols: ... in particular with respect to status codes: It's worth thinking about how that document appli

Re: [OAUTH-WG] OAuth 2.0: client_secret, state

Actually, Brian and I discussed this very topic at some length after the OAuth after-party today. If you think about it, it is impossible to completely separate the Authz Server (AS) from the Protected Resource (PR) -- in all of the possible cases, the AS needs to be able to pass secure me

Re: [OAUTH-WG] What error codes do you need?

misreading). Errors due to incorrect input should be 4xx. On Mon, Mar 22, 2010 at 10:02 PM, Richard Barnes wrote: In case it's helpful, BCP 56 / RFC 3205 provides recommendations for using HTTP as a substrate for other protocols: <https://tools.ietf.org/html/bcp56> ... in particu

Re: [OAUTH-WG] OAuth 2.0: client_secret, state

g the access token, and also the Access Token has a limited lifetime. Hope that helps to clarify things, Allen On 3/22/10 10:19 PM, "Richard Barnes" wrote: If you make the same two assumptions -- shared keys and structured tokens -- then the signing cases can also work via the t

Re: [OAUTH-WG] A display parameter for user authorization requests

This seems rather application-specific. What semantics do these things take on when HTTP is just being used as a transport, e.g., for a virtual world system (see VWRAP)? Also, maybe I'm misunderstanding things here, but since it's the Client that send the browser to the authorization page,

Re: [OAUTH-WG] A display parameter for user authorization requests

ou have in mind? --Richard On Mar 30, 2010, at 6:16 PM, David Recordon wrote: On Tue, Mar 30, 2010 at 3:07 PM, Richard Barnes wrote: This seems rather application-specific. What semantics do these things take on when HTTP is just being used as a transport, e.g., for a virtual world sy

Re: [OAUTH-WG] Renaming expires to expires_in?

Ok, maybe something like "lifetime"? On Apr 5, 2010, at 12:46 PM, Paul Lindner wrote: +1 This would more closely match the nomenclature used by the oauth session extension. On Mon, Apr 5, 2010 at 9:09 AM, David Recordon > wrote: As one of our engineers was implementing a client, they got

Re: [OAUTH-WG] HTTPS requirement for using an Access Token without signatures

To re-iterate and clarify Leif's second point, I would be in favor of making TLS: -- REQUIRED for implementations to support (== MUST) -- RECOMMENDED for deployments to use (== SHOULD) This a pretty universal pattern in IETF protocols. --Richard On Apr 7, 2010, at 7:20 AM, Leif Johansson wr

Re: [OAUTH-WG] HTTPS requirement for using an Access Token without signatures

what? When you access/serve an https:// protected resource you do what? It is not about requiring SSL for bearer token. It is about what you can/should do when accessing an http:// resource. EHL On 4/7/10 7:09 AM, "Richard Barnes" wrote: To re-iterate and clarify Leif's second

Re: [OAUTH-WG] HTTPS requirement for using an Access Token without signatures

igned requests for protected resources using the http URI scheme. EHL On 4/7/10 6:42 PM, "Richard Barnes" wrote: You guys are both right: The recommendation I made before is basically saying that you SHOULD only use tokens without signing on HTTPS resources. --Richard On Apr 7, 201

Re: [OAUTH-WG] HTTPS requirement for using an Access Token without signatures

sending unprotected credentials in the clear. Instead, clients SHOULD obtain and utilize an access token with a matching secret by sending a signed request. Servers MUST accept signed requests for protected resources using the http URI scheme. EHL On 4/7/10 6:42 PM, "Richard Barnes&qu

Re: [OAUTH-WG] HTTPS requirement for using an Access Token without signatures

capital letters), we need to cover the general case, which requires the "MUST implement security, SHOULD use security" pattern. Language about scope is complementary to this. --Richard On Apr 8, 2010, at 5:20 PM, John Kemp wrote: On Apr 8, 2010, at 4:58 PM, Richard Barnes w

Re: [OAUTH-WG] Cache-control for Authorization server

This argument makes sense to me. EHL: Do you have an exception in mind? On Apr 14, 2010, at 10:15 AM, Jeroen van Bemmel wrote: Since HTTPS is used, intermediate proxies aren't a problem. However, a browser might store the response containing the token in "Temporary Internet files" or simi

Re: [OAUTH-WG] Shorter authorization endpoint type names

Why do we need to label the requests according to which flow they belong to? Apologies if this is a dumb question; haven't read the latest draft. On Apr 15, 2010, at 1:31 PM, Eran Hammer-Lahav wrote: I renamed the values of the 'type' parameter as follows: WC-A: web_callback_access_request

Re: [OAUTH-WG] Issue: add refresh token as optional in all access token requests

Sure, this seems sensible, especially with the *optional* part. On Apr 15, 2010, at 3:22 PM, David Recordon wrote: +1, remember discussing this a week or so ago on the list On Thu, Apr 15, 2010 at 12:12 PM, Eran Hammer-Lahav > wrote: Not all the flows return a refresh token for security or

Re: [OAUTH-WG] Rename callback => callback_uri

Could you clarify a little more the environment in which this confusion arose? What do you mean when you say "The protected resource typically accepts 'callback' as a parameter to support JSONP."? What sort of software are you including in this? --Richard On Apr 15, 2010, at 5:41 PM, Lu

Re: [OAUTH-WG] Rename callback => callback_uri

ack&access_token=ACCESS_TOKEN The "callback" parameter is used pretty universally for JSONP requests. For instance, see the Jquery docs: http://api.jquery.com/jQuery.getJSON/ -Original Message- From: Richard Barnes [mailto:rbar...@bbn.com] Sent: Friday, April 16, 2010 9

Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON

On the other hand, if you've already got a JSON or XML library on hand (as many apps these days do), then JSON/XML is a lot easier to handle than form-encoded. Plus, if you're not re-using form-encoding, then there's no risk of being confused with actual "forms" / request parameters. Not

[OAUTH-WG] SD-JWT, implementation and comments

Hi all, My favorite way to understand a draft is to implement it, so I did a quick implementation of SD-JWT while sitting in IETF sessions last week (in Rust, as an extension to the `jwt` crate, which seems pretty mature and widely used). Currently in first-draft form, but in case anyone is inter

[OAUTH-WG] Signed JWK Sets

Hi all, A few of us have been considering use cases for JWTs related to Verifiable Credentials and container signing, which require better "proof of authority" for JWT signing keys. Sharon Goldberg and I wrote up a quick specification for how to sign a JWK set, and how you might extend discovery

Re: [OAUTH-WG] Signed JWK Sets

n, Mar 18, 2024 at 10:23 AM Watson Ladd wrote: > On Sat, Mar 16, 2024 at 10:56 PM Richard Barnes wrote: > > > > Hi all, > > > > A few of us have been considering use cases for JWTs related to > Verifiable Credentials and container signing, which require better &

Re: [OAUTH-WG] Signed JWK Sets

nid.net/specs/openid-federation-1_0.html#section-16.8, which > can be used to indicate key expiration time, etc. > > > > *From:* Michael Jones > *Sent:* Sunday, March 17, 2024 7:00 PM > *To:* Richard Barnes ; oauth@ietf.org WG > *Cc:* Sharon Goldberg > *Subject:* RE: [OAU

Re: [OAUTH-WG] Signed JWK Sets

er. Given that, we reuse the "historical JWK set" format from OpenID Federation, and of course, focus on the "key authority" issue. Obviously, more feedback is welcome, but especially on whether this would be a good thing for the OAuth WG to work on. Thanks, --Richard On Sun, M

[OAUTH-WG] Re: Call for adoption - PIKA

Hi Mike, The intent here is to follow exactly the same security model as current HTTPS-based OP key discovery mechanisms, e.g., OpenID Connect Discovery. With those mechanisms: 1. The only way the issuer is authenticated is via a certificate presented in HTTPS. 2. The only aspect of the URL that

[OAUTH-WG] Re: Call for adoption - PIKA

Hi Giuseppe, To be blunt, solving the use cases we're talking about with OpenID Federation is like doing surgery with a chainsaw. You might achieve the intended goal, but the results will be messy. The trust model we are addressing is one that already exists: A JWT is issued by an issuer identif

[OAUTH-WG] Re: Call for adoption - PIKA

In case it's not clear from other messages in this thread: I think this draft should be adopted. It solves several pressing use cases, with the minimal amount of complexity needed. --Richard On Mon, Jun 10, 2024 at 7:47 AM Rifaat Shekh-Yusef wrote: > All, > > This is an official call for adopt

[OAUTH-WG] Re: Call for adoption - PIKA

from), and I’ll support adoption of the next draft. > > > > -- Mike > > > > *From:* Richard Barnes > *Sent:* Monday, June 10, 2024 8:11 PM > *To:* Rifaat Shekh-Yusef > *Cc:* oauth > *Subject:*

[OAUTH-WG] Re: Call for adoption - PIKA

Hi all, Replying to the top of the thread again to recap the arguments so far. (Hoping the chairs will give us a moment more to discuss before calling cloture.) It seems like Sharon, Rohan, Watson, and I are all on the same page w.r.t. the X.509-based mechanisms in the current draft. In particul

[OAUTH-WG] Re: Call for adoption - PIKA

Hi Giuseppe, Asking whether a technology addresses real-world challenges is a fair question. The point of the current draft is that we have empirical evidence that X.509-based authentication works well for many cases, given the very wide usage of things like OpenID Connect Discovery. PIKA seeks

[OAUTH-WG] Re: Call for adoption - PIKA

hat adopting this draft would result in this attack occurring > in practice. > > > > Thank you, > > -- Mike > > > > *From:* Richard Barnes > *Sent:* Tuesday, June 25, 2024 1:56 PM

[OAUTH-WG] Fwd: New Version Notification for draft-barnes-oauth-pika-01.txt

-- Forwarded message - From: Date: Mon, Jul 8, 2024 at 6:32 PM Subject: New Version Notification for draft-barnes-oauth-pika-01.txt To: Richard L. Barnes , Sharon Goldberg A new version of Internet-Draft draft-barnes-oauth-pika-01.txt has been successfully submitted by Richard Barnes and posted

[OAUTH-WG] Re: We cannot trust Issuers

I would observe that any solution based on garden-variety digital signature (not something zero-knowledge like BBS / JWP) will have problems with issuer/verifier collusion. One-time tokens and batch issuance don't help. There is no such thing as SD-JWT with issuer/verifier collusion resistance. A