Re: [OAUTH-WG] updated Distributed OAuth ID

Thanks for the review and suggestions, Jared. A token (pun intended!) attempt at addressing your comments follows. Though I don't think I actually discussed it with my co-authors, I did think about the link relation for the AS being the issuer rather than pointing to the metadata document under ".

Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt

it might > be less it won't be more. > > -Ekr > > > On Fri, Jun 1, 2018 at 3:15 PM, Brian Campbell > wrote: > >> I suspect that the vast majority of time C's permissions won't matter at >> all. But I do think there are legitimate cases wher

Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt

's permissions > matter at all? So, say that the resource is accessible to C but not A? > > -Ekr > > > > > On Fri, Jun 1, 2018 at 11:47 AM, Brian Campbell < > bcampb...@pingidentity.com> wrote: > >> Hi Eric, >> >> Apologies for my somew

Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt

dinarily not access, but B can. > If C has this delegation, can C access the resource? I.e., is B giving C > his authority or just passing on A's authority? It seems pretty important > for B to know that before he gives the token to C. > > -Ekr > > > On Thu, May 17, 2018

Re: [OAUTH-WG] Last Call: (OAuth 2.0 Device Flow for Browserless and Input Constrained Devices) to Proposed Standard

On Wed, May 30, 2018 at 6:06 PM, William Denniss wrote: > > On Wed, May 30, 2018 at 3:48 PM, Brian Campbell < > bcampb...@pingidentity.com> wrote: > >> I realize this is somewhat pedantic but I don't think referencing 4.1.2.1 >> works given how RFC 6749 set t

Re: [OAUTH-WG] Last Call: (OAuth 2.0 Device Flow for Browserless and Input Constrained Devices) to Proposed Standard

I realize this is somewhat pedantic but I don't think referencing 4.1.2.1 works given how RFC 6749 set things up. Rather I believe that the device flow needs to define and register "access_denied" as a valid token endpoint response error code (it's not a token endpoint response error per RFC 6749 s

Re: [OAUTH-WG] Last Call: (OAuth 2.0 Device Flow for Browserless and Input Constrained Devices) to Proposed Standard

In reading the draft (again) I noticed a couple of things that, while maybe not substantive, seemed like they were worth raising here in last call: 1: In Section 3.5 a new 'expired_token' error code is defined for when the

Re: [OAUTH-WG] OAUTB for Access Token in Implicit Grant

Yeah, that's what is implied. At least given the way that https://tools.ietf.org/html/draft-ietf-tokbind-https provides to signal to the client to reveal the Referred Token Binding. I've heard that there's some potential for the Fetch spec to provide some APIs or controls around Token Binding, whi

Re: [OAUTH-WG] Grant flow for delegated auth

Take a look at RFC 7523 's JWT Authorization Grant. On Thu, May 24, 2018 at 1:17 AM, Sergey Ponomarev wrote: > Hi, > > My Auth Server (AS) implementation has a client (server of another > platform) which makes authorization on it's side but it needs to popul

Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt

Well, it's already called the "actor claim" so the claimed part is kind of implied. And "claimed actor claim" is a rather awkward. Really, all JWT claims are "claimed something" but they don't include the "claimed" bit in the name. RFC 7519, for example, defines the subject claim but not the claime

Re: [OAUTH-WG] OAUTB for Access Token in Implicit Grant

Typically when an access token is issued via the implicit grant directly from the authorization endpoint, it is for a client that is running as script in the user-agent. The AS binds the access token to the referred token binding, which would be the token binding between the user-agent (where the c

Re: [OAUTH-WG] review of draft-ietf-oauth-mtls-08

Thanks Samuel (even though this doc already went through WGLC!). I'll attempt to address your comments/questions inline below. On Sat, May 12, 2018 at 4:21 PM, Samuel Erdtman wrote: > Hi > > Thanks for a great document. > And thank you too! I have some minor comments. > > in Abstract > “...ba

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

has *been* published sigh On Mon, May 7, 2018 at 2:14 PM, Brian Campbell wrote: > A new draft of the OAuth 2.0 Mutual TLS Client Authentication and > Certificate Bound Access Tokens specification has published with changes > addressing review comments from Working Group Last Call.

[OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-08.txt

tual TLS Client Authentication and Certificate Bound Access Tokens Authors : Brian Campbell John Bradley Nat Sakimura Torsten Lodderstedt Filename: draft-ietf-oauth-mtls-08.txt Pages

[OAUTH-WG] JWT BCP Acknowledgements (was Fwd: New Version Notification for draft-ietf-oauth-jwt-bcp-02.txt)

AFAIK, Tim McLean was the first to bring the HMAC/RSA switching attack to the attention of JWS/JWT implementers - https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/ Perhaps he should be acknowledged similar to how Antonio is for the invalid point attack? I've also provid

[OAUTH-WG] deterministic ECDSA (was Fwd: New Version Notification for draft-ietf-oauth-jwt-bcp-02.txt)

New in this version of draft-ietf-oauth-jwt-bcp is a rather strong recommendation to use deterministic ECDSA from RFC 6979 (the new text with a SHOULD is copy/pasted below for the lazy among us that might be reading this). Is this consistent with the general thinking or advice out of the IETF or C

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07

Wearing my editor's hat here (did I do that right?) and looking to bring this to a close so the draft can proceed - I don't see a consensus for additional confirmation methods in this draft. On Tue, May 1, 2018 at 3:08 AM, Neil Madden wrote: > JOSE and many other specs have allowed algorithms to

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07

On Mon, Apr 30, 2018 at 9:57 AM, Neil Madden wrote: > > > On 30 Apr 2018, at 15:07, John Bradley wrote: > > > My concern is that people will see a bigger number and decide it is > better if we define it in the spec. > > We may be getting people to do additional work and increasing token size > w

Re: [OAUTH-WG] scp claim in draft-ietf-oauth-token-exchange-12

draft -13 was just published with these changes On Mon, Apr 23, 2018 at 2:15 PM, George Fletcher wrote: > +1 > > > On 4/23/18 3:13 PM, Brian Campbell wrote: > > I just noticed/remembered that the draft also currently defines a "cid" > claim for the client ident

Re: [OAUTH-WG] scp claim in draft-ietf-oauth-token-exchange-12

-- Mike > > > > *From:* OAuth *On Behalf Of * Brian Campbell > *Sent:* Wednesday, April 18, 2018 8:17 AM > *To:* Torsten Lodderstedt > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] scp claim in draft-ietf-oauth-token-exchange-12 > > &g

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07

dd (well-known algorithms that are widely available) so > it might make sense to just toss them in now? I think it’s fine either way. > > — Justin > > On Apr 19, 2018, at 12:23 PM, Brian Campbell > wrote: > > Okay, so I retract the idea of metadata indicating the hash alg/cnf >

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07

n’t think this is the correct place to be deciding this. > > We could say that if new thumbprints are defined the AS and RS can decide > to use them as necessary. > That is sort of the situation we have now. > > The correct solution may be a thousand rounds of PBKDF2 or something

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07

Thanks. Will do. On Thu, Apr 19, 2018 at 8:57 AM, Benjamin Kaduk wrote: > I would go ahead and put them in. The blog post might get some > pushback, but I think there's plenty of precedent for academic > papers. > > -Ben > > On Wed, Apr 18, 2018 at 09:34:23AM -

Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt

Eric, I realize you weren't particularly impressed by my prior statements about the actor claim but, for lack of knowing what else to say, I'm going to kind of repeat what I said about it over in the Phabricator tool and add a little col

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07

g post [1] is the best concise summary of attacks I could > find. Most of these attacks have been published as Black Hat talks and I > can’t seem to find definitive references or good survey papers (beyond [2], > which is a little older). > > > > Let me know what you think, > &g

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Incremental Authorization

I support adoption of OAuth 2.0 Incremental Authorization as a WG document. On Mon, Apr 16, 2018 at 8:47 AM, Rifaat Shekh-Yusef wrote: > All, > > We would like to get a confirmation on the mailing list for the adoption of > the *OAuth 2.0 Incremental Authorization* as a WG document > https://dat

Re: [OAUTH-WG] scp claim in draft-ietf-oauth-token-exchange-12

The draft-ietf-oauth-token-exchange document makes use of scope and at some point in that work it came to light that, despite the concept of scope being used lots of places elsewhere, there was no officially registered JWT claim for scope. As a result, we (the WG) decided to have draft-ietf-oauth-t

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07

That's true about it being opaque to the client. I was thinking of client metadata (config or registration) as a way for the AS to decide if to bind the AT to a cert. And moving from a boolean to a conf method as an extension of that. It would be more meaningful in RS discovery, if there was such a

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07

hu, Apr 12, 2018 at 3:03 AM, Neil Madden wrote: > Hi Brian, > > Thanks for the detailed responses. Comments in line below (marked with > ***). > > Neil > > On Wednesday, Apr 11, 2018 at 9:47 pm, Brian Campbell < > bcampb...@pingidentity.com> wrote: > Thanks for the

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07

:07 pm, John Bradley > wrote: > +1 > > On Wed, Apr 4, 2018, 5:42 PM Brian Campbell > wrote: > >> Strongly agree with Justin that any kind of TLS header forwarding >> standards like that are well beyond the scope of this spec. >> >> >> On Fri, M

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07

in line below (marked with > ***). > > > > Neil > > > > > On Wednesday, Apr 11, 2018 at 9:47 pm, Brian Campbell < > bcampb...@pingidentity.com (mailto:bcampb...@pingidentity.com)> wrote: > > > On Thu, Mar 29, 2018 at 9:18 AM, Neil Madden < > neil.mad...@fo

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07

Thanks for the review and feedback, Neil. I apologize for my being slow to respond. As I said to Justin recently , I've been away from things for a while. Also there's a lot here to get through so took me some time. It looks

Re: [OAUTH-WG] Review of oauth-mtls-07

Thanks for the responses and additional suggestions. Also sorry for the slow reply on my end - I was away on a nice long spring break with the family, which was immediately followed by some other travel. I totally get what you are saying about DN comparison and agree with the sentiment. I've just

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07

Strongly agree with Justin that any kind of TLS header forwarding standards like that are well beyond the scope of this spec. On Fri, Mar 30, 2018 at 10:02 PM, Justin Richer wrote: > I don’t believe this is the spec to define TLS header forwarding standards > in. > > — Justin > > > On Mar 30,

Re: [OAUTH-WG] Review of oauth-mtls-07

Thanks for the detailed review, Justin. Replies are inline below... On Tue, Mar 20, 2018 at 5:52 PM, Justin Richer wrote: > As promised in yesterday’s meeting, here’s my review of the oauth-mtls > draft. We’ve recently implemented the spec from the AS and RS side for an > as-yet-unreleased vers

Re: [OAUTH-WG] JSON Web Token Best Current Practices draft describing Explicit Typing

ell, to > explicitly type the entire Nested JWT. > > > > -- Mike > > > > *From:* Brian Campbell > *Sent:* Monday, July 17, 2017 10:53 AM > *To:* Phil Hunt (IDM) > *Cc:* Mike Jones ; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] JSON Web Token Best Current Pra

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

That works for me On Wed, Mar 21, 2018 at 7:34 PM, Torsten Lodderstedt < tors...@lodderstedt.net> wrote: > Hi all, > > thanks for your feedback. Here is my text proposal for section 3.8.1. > > —— > > Attackers could try to utilize a user's trust in the authorization >server (and its URL in pa

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

Doing redirection in error conditions relates to OpenID Connect flows too. There's been some related discussion recently about it in this issue: https://bitbucket.org/openid/connect/issues/1023/clarify- that-returning-errors-to-the On Tue, Mar 20, 2018 at 7:38 PM, Brian Campbell wrote:

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

at 4:44 PM, Torsten Lodderstedt < tors...@lodderstedt.net> wrote: > Hi Brian, > > Am 20.03.2018 um 15:37 schrieb Brian Campbell >: > > +1 to what Travis said about 3.8.1 > > The text in 3.8 about Open Redirection is new in this most recent -05 > version of the draft so th

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

+1 to what Travis said about 3.8.1 The text in 3.8 about Open Redirection is new in this most recent -05 version of the draft so this is really the first time it's been reviewed. I believe 3.8.1 goes too far in saying "this draft recommends that every invalid authorization request MUST NOT automat

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07

I talked with Justin briefly yesterday after the meeting and he pointed out that the document is currently rather ambiguous about whether or not the base64 pad "=" character is to be used on the encoding of "x5t#S256" member. The intent was that padding be omitted and I'll take it as a WGLC comment

Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.txt

And let us not forget about JWS unencoded payload https://tools.ietf.org/html/rfc7797 On Mar 19, 2018 11:41 AM, "Samuel Erdtman" wrote: > Hi, > > Adding an additional proposal to the table. Mike Jones, Anders Rundgren > and I have created a version of JWS there the signed JSON data does not > ha

Re: [OAUTH-WG] IETF101 Draft Agenda

Looks okay to me too. I don't think I'll have anywhere close to 20 minutes on draft-ietf-oauth-token-bindingfor this meeting. But having some extra time isn't a bad thing. On Wed, Mar 7, 2018 at 11:58 AM, William Denniss wrote: > Looks good to me. > > > On Wed, Mar 7, 2018 at 10:53 AM Rifaat Sh

Re: [OAUTH-WG] draft-ietf-oauth-mtls-07: jwks_uri with registered x5t#S256

I'd say it's really an implementation detail. But I think both 1 or 2 would work. I'd probably opt for 1 because a JWK will always have the key while "x5t#S256" is optional so some more work needs to happen to ensure it is present and/or deal with it being absent. This harks back to the question y

Re: [OAUTH-WG] Call for agenda items

I hadn't previously been planning on it but am happy to do so. On Tue, Mar 6, 2018 at 8:22 AM, Rifaat Shekh-Yusef wrote: > Nat, > > During the interim meeting, 3 drafts mentioned in the context of *Distributed > OAuth*: > > https://tools.ietf.org/html/draft-sakimura-oauth-meta-08 > https://tools

[OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-token-binding-06.txt

work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Token Binding Authors : Michael B. Jones Brian Campbell John Bradley William Denniss Filename

[OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-07.txt

available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens Authors : Brian Campbell

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

ny Nadalin Brian Campbell John Bradley Chuck Mortimore Filename: draft-ietf-oauth-token-exchange-12.txt Pages : 33 Date: 2018-01-30 Abstract: This specification defines a protocol f

Re: [OAUTH-WG] rfc6749 question about the optional use of the client_id in the request body

Mike > > > > *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Brian > Campbell > *Sent:* Monday, January 29, 2018 11:58 AM > *To:* Tom Van Oppens > *Cc:* oauth > > *Subject:* Re: [OAUTH-WG] rfc6749 question about the optional use of the > client_id in the r

Re: [OAUTH-WG] rfc6749 question about the optional use of the client_id in the request body

gt; @all > > Shoudln't we define or maybe in the OIDC spec add some information so that > the AS needs to do something with that clien_id in the body, saying it must > match the client_id coming in somewhere else ? > Or at least have the AS do something with it . > > >

Re: [OAUTH-WG] rfc6749 question about the optional use of the client_id in the request body

Hi Tom, Indeed RFC 6749 is not well written with respect to this situation and unfortunately leaves some room for varied interpretations. However, in my own not entirely uninformed view having worked on this stuff for awhile now, it is erroneous to interpret the presence of the client_id parameter

Re: [OAUTH-WG] AD Review: draft-ietf-oauth-token-exchange-09

Yes, thank you for the review, Eric. A new draft -11 has been published incorporating the feedback. On Fri, Dec 29, 2017 at 10:48 AM, Mike Jones wrote: > Thanks for the useful review, Eric. I’ll work with Brian and the crew to > incorporate this feedback. > > > >

Re: [OAUTH-WG] draft-hardt-oauth-mutual-01

Inline also... On Tue, Jan 16, 2018 at 2:25 PM, Dick Hardt wrote: > Comments inline ... > > On Tue, Jan 16, 2018 at 1:11 PM, Brian Campbell < > bcampb...@pingidentity.com> wrote: > >> >> *On client_id:* >> With the authorization_code code grant (sec

Re: [OAUTH-WG] draft-hardt-oauth-mutual-01

eversed. Given that, it is unclear > why client_id would not be required. Would you elaborate? > > *response* > Agree a response should be defined. 200 if ok, 400 if invalid. Any reason > for doing more? > > /Dick > > > On Tue, Jan 16, 2018 at 9:27 AM, Brian Campbell &

Re: [OAUTH-WG] draft-hardt-oauth-mutual-01

A few thoughts on the new draft and/or reiterating comments from the call earlier. "[DH: should this be a URI?]" - yes, the grant type should be a URI because, for better or worse, that's how OAuth allows for new grants https://tools.ietf.org/html/rfc6749#section-4.5 (the device flow and JWT autho

[OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-06.txt

is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens Authors : Brian Campbell

Re: [OAUTH-WG] [token-exchange] Parameters to support external token exchange

wrote: > On Fri, Dec 8, 2017 at 12:41 PM, Brian Campbell > wrote: > > I guess I'm going to kind of restate some of what I said in that earlier > > thread and a bit more. The access and refresh token URIs from the draft > are > > intended to indicate that suc

Re: [OAUTH-WG] WGLC for OAuth 2.0 Device Flow for Browserless and Input Constrained Devices

I couldn't get the QR code to work... ;) On Mon, Nov 27, 2017 at 6:55 AM, Rifaat Shekh-Yusef wrote: > All, > > As discussed in Singapore, we are starting a WGLC for the > *draft-ietf-oauth-device-flow-07* document, starting today and ending on > December 11, 2018. > https://datatracker.ietf.org/

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

used, > e.g. using the word "surveillance" as mentioned in 5.1.1 : "Surveillance > is the observation or monitoring > of an individual’s communications or activities", but the threat should be > mentioned one way or another. Denis > > I believe the text would

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

m of the Web Authorization Protocol WG of the IETF. > > Title : OAuth 2.0 Token Exchange > Authors : Michael B. Jones > Anthony Nadalin > Brian Campbell > John Bradley >

Re: [OAUTH-WG] [token-exchange] Parameters to support external token exchange

I guess I'm going to kind of restate some of what I said in that earlier thread and a bit more. The access and refresh token URIs from the draft are intended to indicate that such tokens

Re: [OAUTH-WG] Token Exchange Implementations

With a little searching I came across a couple other implementations: Indigo IAM https://indigo-dc.gitbooks.io/iam/content/doc/user-guide/oauth_token_exchange.html Unity IdM http://www.unity-idm.eu/documentation/unity-2.1.0/manual.html#_token_exchange On Thu, Nov 23, 2017 at 9:17 AM, Rifaat Shek

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

I am not aware of any IPR on the token exchange document. On Thu, Nov 23, 2017 at 9:14 AM, Rifaat Shekh-Yusef wrote: > Authors, > > As part of the write-up for the Token Exchange document, we need an IPR > disclosure from all of you. > > Are you aware of any IPR related to the following Token Ex

Re: [OAUTH-WG] New Version of draft-sakimura-oauth-meta for the discussion of draft-hardt-oauth-distributed

And, for what it's worth, here's the (poorly named) resource indicators draft that was mentioned during the same discussion. https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02 On Wed, Nov 15, 2017 at 6:11 PM, Nat Sakimura wrote: > I just revved the expired and archived dra

Re: [OAUTH-WG] cert spoofing in mtls & short-lived certs

The expectation/assumption is that the SubjectDN would be a stable identifier through re-issuance of certificates, regardless of whether they be short or long term. We've had basically this as a product feature for years and use of the SubjectDN as the identifier hasn't been an issue. And it's not

Re: [OAUTH-WG] JSON Web Token Best Current Practices draft describing Explicit Typing

xpress it in the draft. Will do. > > > >-- Mike > > > > *From:* Brian Campbell [mailto:bcampb...@pingidentity.com] > *Sent:* Monday, July 17, 2017 11:53 AM > *To:* Phil Hunt (IDM) > *Cc:* Mike Jones ; oauth@ie

[OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-05.txt

ofile for OAuth 2.0 Authors : Brian Campbell John Bradley Nat Sakimura Torsten Lodderstedt Filename: draft-ietf-oauth-mtls-05.txt Pages : 18 Date: 2017-

Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-04.txt

agraph / 1st line > "allows for the use" -> "allows use" > (remove "for the", but I'm not sure because I'm not a native English > speaker.) > > 6.1. / 1st paragraph / 2nd line > "it is latest" -> "it is the latest" &g

Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-04.txt

mments about it. > > Will sender-constrained access tokens also work in a token exchange > scenario? > > (draft-ietf-oauth-token-exchange-09) > > Vladimir > > On 13/10/17 01:07, Brian Campbell wrote: > > I'm pleased to announce that a new draft of "Mutual TLS

[OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-04.txt

g Cc: oauth@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : Mutual TLS Profile for OAuth 2.0 Authors : Brian Campbell

Re: [OAUTH-WG] oauth - New Meeting Session Request for IETF 100

Can we possibly also try and avoid conflicts with tokbind? On Wed, Sep 27, 2017 at 11:25 AM, IETF Meeting Session Request Tool < session-requ...@ietf.org> wrote: > > > A new meeting session request has just been submitted by Rifaat > Shekh-Yusef, a Chair of the oauth working group. > > >

Re: [OAUTH-WG] draft-ietf-oauth-mtls-03: jwk / x5c sanity checks when registering for pub_key_tls_client_auth

huvinov < vladi...@connect2id.com> wrote: > > On 29/08/17 18:14, Brian Campbell wrote: > > Sec 4.7 of RFC 7517 <https://tools.ietf.org/html/rfc7517#section-4.7>, > > which defines "x5c" for JWK, says that the "key in the first certificate > > MUST m

Re: [OAUTH-WG] draft-ietf-oauth-mtls-03: jwk / x5c sanity checks when registering for pub_key_tls_client_auth

Sec 4.7 of RFC 7517 , which defines "x5c" for JWK, says that the "key in the first certificate MUST match the public key represented by other members of the JWK." Thus, how I read it anyway, the check you mention is already a requirement of the JWK l

[OAUTH-WG] some implementation feedback with the PKI method of OAuth MTLS client authentication

Some feedback was received recently off-list that pointed out difficulties with implementation around the "tls_client_auth_root_dn" constraint in the PKI method of OAuth MTLS client authentication from draft-ietf-oauth-mtls-03. Basically the feedback was that popular web servers such as Nginx and A

Re: [OAUTH-WG] draft-ietf-oauth-mtls-03: enforcing mutual_tls_sender_constrained_access_tokens

"invalid_client" is the appropriate error, if the client is configured/registered for MTLS authentication, because it's effectively failed client authentication. I would say that "invalid_request" is probably the appropriate error for a public client with mutual_tls_sender_constrained_access_token

Re: [OAUTH-WG] draft-ietf-oauth-mtls-03 - auth to other endpoints?

Yeah, we definitely didn't intend for it to be exclusive to the token endpoint. I think the text kinda came out that way as an artifact of the way some of these specs are layered and when they were written as well as some assumptions on my part that it would be understood that this client authentic

Re: [OAUTH-WG] draft-ietf-oauth-mtls-03: resource server error code

"invalid_token" according to the last paragraph of https://tools.ietf.org/html/draft-ietf-oauth-mtls-03#section-3 which says that the RS, 'MUST verify that the certificate matches the certificate associated with the access token. If they do not match, the resource access attempt MUST be rejected w

Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-03.txt

straightforward and/or less error prone. I don't necessarily agree but wanted to bring the discussion back to the list. On Fri, Aug 4, 2017 at 1:17 PM, Vladimir Dzhuvinov wrote: > What are the potential uses of the x5c parameter? > > Vladimir > > > On 04/08/17 21:13, Brian Campbell wr

Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-03.txt

Just wanted to note that, in an off-list exchange, John has pushed back on the idea to potentially drop mention of using x5c. On Wed, Aug 2, 2017 at 9:29 AM, Brian Campbell wrote: > Thanks for the review, Vladimir. > > The text about which you have questions was written by Torsten (

Re: [OAUTH-WG] draft-ietf-oauth-closing-redirectors has obsolete header for referer control

upport until Chrome 61 gets out of beta. > > Is chrome showing a user visible error with the old header? > > Easiest thing would be to use the new header and deny access to anyone > still using IE:) > > John B. > > > On Aug 3, 2017, at 12:43 PM, Brian Campbell > wrote:

Re: [OAUTH-WG] draft-ietf-oauth-closing-redirectors has obsolete header for referer control

port but they are a small > number in general. > > John B. > > > On Aug 2, 2017, at 6:46 PM, Brian Campbell > wrote: > > Not sure of the status at this point (it is expired) but the > draft-ietf-oauth-closing-redirectors WG document in > https://tools.ietf.org/html/draft-i

[OAUTH-WG] draft-ietf-oauth-closing-redirectors has obsolete header for referer control

Not sure of the status at this point (it is expired) but the draft-ietf-oauth-closing-redirectors WG document in https://tools.ietf.org/html/draft-ietf-oauth-closing-redirectors-00#section-2.3 suggests using the Content Security Policy header to limit the information sent in the referer something l

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

em in > one section (2.1 as it is now). > > The two methods are distinctive enough, and implementers should easily > recognise they can implement just one of them. > > Vladimir > > > On 01/08/17 22:57, Brian Campbell wrote: > > Thanks Justin. > > > >

Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-03.txt

t; its respective authentication data at the authorization server. > > I don't understand this - "in conjunction with a trusted X.509 certificate > source" > > > Thanks, > > Vladimir > > On 28/07/17 21:33, Brian Campbell wrote: > > A new draft of &

Re: [OAUTH-WG] [token-exchange] exchanging between issuers/domains

e? >> >> >> In order to progress on this topic, I believe that we first need an >> architecture paper with a clear description of the trust relationships and >> an identification of the privacy issues. >> >> Denis >> >> On Sat, Jul 29, 201

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

unction(s) other than SHA-256 need to be used for > certificate thumbprints > > > > -- Forwarded message -- > From: > Date: Fri, Jul 28, 2017 at 12:25 PM > Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt > To: i-d-annou...@ietf.org > Cc

Re: [OAUTH-WG] [token-exchange] exchanging between issuers/domains

potentially >> proprietary and different between each and every STS? On the opposite end, >> when you want to convert to an external token, the STS either has 3 options >> for the client to specify that it wants an external token. 1) a >> proprietary response type, 2) a proprieta

Re: [OAUTH-WG] [token-exchange] exchanging between issuers/domains

STS > on how it wants the client to formulate a cross-domain exchange. I still > think a "subject_issuer" and "requested_issuer" are the clearest and > simplest way to enable such an interaction. > > On 7/28/17 6:28 PM, Brian Campbell wrote: > > The urn:ie

Re: [OAUTH-WG] JWT BCP on Compression in JWE

Hi Yaron, I don't actually know, which is why I raised the question in hopes that, if possible, the BCP could provide some practical and actionable advice. But I'll try and explain my (maybe naive) thoughts. As I understand it CRIME/BREACH are adaptive-chosen-plaintext attacks that work via malic

Re: [OAUTH-WG] [token-exchange] exchanging between issuers/domains

hing that is defined at all. In OpenID connect, an issuer id can be > any URL. > > IMO, adding optional "subject_token_issuer" and "requested_issuer" > parameters only clarifies and simplifies the cross-domain case. If you > don't like "issuer"

Re: [OAUTH-WG] [token-exchange] exchanging between issuers/domains

In general, an instance of an AS/STS can only issue tokens from itself. The audience/resource parameters tell the AS/STS where the requested token will be used, which will influence the audience of the token (and maybe other aspects). But the issuer of the requested token will be the AS/STS that is

[OAUTH-WG] JWT BCP on Compression in JWE

On critique of JWT I've seen a few times can be paraphrased as "JWT supports compressed plaintext so, because of CRIME and BREACH, it is dangerous and stupid." It's very possible that I am stupid (many on this list will likely attest to it) but I don't see the applicability of those kinds of chose

[OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-03.txt

This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : Mutual TLS Profile for OAuth 2.0 Authors : Brian Campbell John Bradley Nat Sakimura Torsten Lodderstedt Fil

Re: [OAUTH-WG] [jose] preventing confusion of one kind of JWT for another in JWT BCP

t what > values are acceptable. > > > > Jim > > > > > > *From:* jose [mailto:jose-boun...@ietf.org] *On Behalf Of *John Bradley > *Sent:* Thursday, July 27, 2017 3:24 PM > *To:* Brian Campbell > *Cc:* Nathaniel McCallum ; oauth ; > j...@ietf.org; Phil Hunt

Re: [OAUTH-WG] [jose] preventing confusion of one kind of JWT for another in JWT BCP

problem. Yes, a class of attack could exist where an attacker > substitutes a valid JWT from one security context into another > context. But isn't this resolved by audience validation? > > On Thu, Jul 27, 2017 at 3:34 PM, Brian Campbell > wrote: > > The draft describes it

Re: [OAUTH-WG] [jose] preventing confusion of one kind of JWT for another in JWT BCP

les from being confused with older JWTs, which > 'typ' solves (as does your proposal of 'crit' and 'p', but requires more > bytes) > > Preventing existing JWT implementations from being confused with new JWT > profiles. 'crit' can solve that f

Re: [OAUTH-WG] [jose] preventing confusion of one kind of JWT for another in JWT BCP

may just be > ignorant. > > On Thu, Jul 27, 2017 at 2:49 PM, Brian Campbell > wrote: > > During the first WG meeting last week I asked if use of the JOSE "crit" > > (Critical) Header Parameter had been considered as a recommendation for > > preventing confusi

[OAUTH-WG] preventing confusion of one kind of JWT for another in JWT BCP

During the first WG meeting last week I asked if use of the JOSE "crit" (Critical) Header Parameter had been considered as a recommendation for preventing confusion of one kind of JWT for another. Time was running short in the meeting so there wa

Re: [OAUTH-WG] Call for Adoption: JSON Web Token Best Current Practices

+1 for adoption On Thu, Jul 20, 2017 at 8:47 PM, Phil Hunt (IDM) wrote: > +1 adoption > > Phil > > On Jul 20, 2017, at 11:26 AM, John Bradley wrote: > > I support adoption > > On Jul 20, 2017, at 2:37 PM, Rifaat Shekh-Yusef > wrote: > > All, > > We would like to get a confirmation on the maili

Re: [OAUTH-WG] JSON Web Token Best Current Practices draft describing Explicit Typing

Could some more guidance be provided around how to use the explicit typing with nested JWTs? I'd imagine that the "typ" header should be in the header of the JWT that is integrity protected by the issuer? On Tue, Jul 4, 2017 at 9:58 PM, Phil Hunt (IDM) wrote: > +1 > > Thanks Mike. > > Phil > >

<    2   3   4   5   6   7   8   9   10   11   >