Re: [OAUTH-WG] Resource Indicators Implementations

Ping has an implementation that was done years ago but using a different parameter name (see 'aud' at https://documentation.pingidentity.com/pingfederate/pf92/index.shtml#adminGuide/tokenEndpoint.html for one example). So it's not this exact draft per se but is conceptually the same. And problems

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

(including Ben & Neil) think? On Fri, Jan 4, 2019 at 2:55 PM Benjamin Kaduk wrote: > On Fri, Dec 28, 2018 at 03:55:15PM -0700, Brian Campbell wrote: > > I > > suspect that not having client certs set up is the situation for the vast > > majority of users and their browsers. A

Re: [OAUTH-WG] Resource Indicators - IPR Disclosure

I am not aware of any IPR related to this document. On Fri, Jan 4, 2019 at 8:43 AM Rifaat Shekh-Yusef wrote: > Authors, > > As part of the write-up for the Resource Indicators document, we need an > IPR disclosure from all of you. > > Are you aware of any IPR related to the following Resource

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

cept a TLS client > certificate without supporting this? > > — Neil > > > On 17 Dec 2018, at 20:26, Brian Campbell 40pingidentity@dmarc.ietf.org> wrote: > > > > While there's been some disagreement about the specific wording etc., > there does seem to be general cons

[OAUTH-WG] Fwd: [Openid-specs-mobile-profile] Issue #145: 7.3 expires_in and interval should be required to be integers (openid/mobile)

The below issue was raised in an OIDF WG about the so called CIBA draft, which has a number of significant similarities to the Device Flow, including the expires_in and interval response parameters noted in the issue. So *maybe* something to consider for the OAuth 2.0 Device Flow for Browserless

[OAUTH-WG] MTLS and in-browser clients using the token endpoint

While there's been some disagreement about the specific wording etc., there does seem to be general consensus coming out of this WG to, in one form or another, recommend against the use of the implicit grant in favor of authorization code. In order to follow that recommendation, in-browser

Re: [OAUTH-WG] draft-ietf-oauth-token-exchange comments (RESTful / OIDC claims)

The OAuth framework itself isn't particularly RESTful so it's not really specific to token exchange. This document just makes mention of it in the context of talking about the shift from XML/SOAP/WS* to JSON/HTTP as one of the motivations for its existence. There's nothing precluding sending

Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-token-exchange-16: (with DISCUSS and COMMENT)

I apologize for the slow response, Ben. I was on vacation with my family around the Thanksgiving holiday when the ballot position came in. And even on returning and starting to work on it, there's an awful lot here to get through and this kind of thing is very time consuming for me. But thank you

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

FWIW I'm somewhat sympathetic to what Vittorio, Dominick, etc. are saying here. And that was kind of behind the comment I made, or tired to make, about this in Bangkok, which was (more or less) that I don't think the WG should be killing implicit outright but rather that it should begin to

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

On Sat, Dec 1, 2018 at 5:01 AM Torsten Lodderstedt wrote: > > my proposal is to add the following definition (based on 3.8.1.2) to a new > „Terminology" section or to section 2.1.2: > > A sender constrained access token scopes the applicability of an access > token to a certain sender. This

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

and issue short living and privilege restricted access tokens.. >> >>>> >> >>>> Sender constrained access tokens in SPAs need adoption of token >> binding or alternative mechanism. mtls could potentially work in &g

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt wrote: > > Am 15.11.2018 um 23:01 schrieb Brock Allen : > > > > So you mean at the resource server ensuring the token was really issued > to the client? Isn't that an inherent limitation of all bearer tokens > (modulo HTTP token binding, which

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

> > kind regards, > Torsten. > > Am 30.11.2018 um 21:02 schrieb Brian Campbell >: > > As was pointed out to me in WGLC review of the MTLS document, > "sender-constrained" has or is likely to be interpreted with a pretty > specific meaning of the to

Re: [OAUTH-WG] draft-ietf-oauth-token-exchange/audience & draft-ietf-oauth-resource-indicators

Seems correct, yes. On Fri, Nov 30, 2018 at 1:32 PM Hannes Tschofenig wrote: > Hi all, > > Token exchange registers the 'resource' parameter, at least to a large > extend, and draft-ietf-oauth-resource-indicators indicates this in the IANA > consideration section. > > What isn't mentioned in

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

As was pointed out to me in WGLC review of the MTLS document, "sender-constrained" has or is likely to be interpreted with a pretty specific meaning of the token being bound to the client and the client authenticating itself to the resource and the resource checking all that matches up. That makes

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

Big +1 here. I'd be in favor of the document discussing the potential benefits of tying the refresh token to a session in some situations but very much agree that the spectrum of desired behaviors is much too wide to normatively recommend any particular option. On Wed, Nov 28, 2018 at 11:19 PM

Re: [OAUTH-WG] Alissa Cooper's Discuss on draft-ietf-oauth-token-exchange-16: (with DISCUSS and COMMENT)

Thank you, Alissa, for the review. Please see below for inline comments/responses and note that this is also my response to your last message on the related thread at https://mailarchive.ietf.org/arch/msg/oauth/MKqEIsb8TJCFUNl3vF-bB38nWv4 On Tue, Nov 20, 2018 at 12:50 PM Alissa Cooper wrote: >

Re: [OAUTH-WG] Adam Roach's Discuss on draft-ietf-oauth-token-exchange-16: (with DISCUSS and COMMENT)

Thank you for the review, Adam. I do sincerely hope that your time with the document didn't drive you to drink (too much anyway). Please see below for inline comments/responses. On Tue, Nov 20, 2018 at 4:39 PM Adam Roach wrote: > Adam Roach has entered the following ballot position for >

[OAUTH-WG] Token Binding & implicit

During the first OAuth session in Bangkok the question "what to do about token binding & implicit?" was raised. There was some discussion but session time was limited and we had to move on before any real consensus was reached. So I thought I'd bring the question to the WG list to generate some

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

I might suggest that neither of those are really best current practice per se. Using key constrained tokens is more of an aspirational recommendation for what would be good security practice than it is something that's done much for real in practice today. On Sat, Nov 17, 2018, 4:07 AM Torsten

Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-mtls

gt; > > >>> — Justin > > >>> > > >>> On Nov 6, 2018, at 3:52 PM, Evan Gilman wrote: > > >>> > > >>> Response(s) inline > > >>> > > >>> On Mon, Nov 5, 2018 at 11:53 PM Neil Madden < > neil.mad...@f

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

> > Does this "MUST be single-use” not effectively already require the code > is invalidated after first use? If so why downgrade this to a “SHOULD”? > > You are right. My feeling is single use can turn out to be a really hard > to implement requirement. That’s why I would like to relax it. Given

Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-mtls

be an opaque > identifier? > > > There are some extra things we could do if we attached type-specific > semantics to the matching (e.g. DNS wildcarding etc), however I think > that continuing to use the values as opaque identifiers would get us > most of what we need wh

Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-mtls

Thanks Evan for bringing this to the WG's attention. More or less the same question/issue was raised yesterday in the area director's review of the document as well. I plan to bring this up as a discussion item in the meeting today. But my sense from some early discussions is that there is likely

Re: [OAUTH-WG] security considerations for draft-ietf-oauth-mtls-12

er asked about > it, but I raised this concern because it was not mentioned in the > security considerations section. > > On Thu, Nov 1, 2018 at 7:37 AM Brian Campbell > wrote: > > > > To be honest, I thought that was a relatively well known aspect of TLS > 1.2 (and prior

Re: [OAUTH-WG] security considerations for draft-ietf-oauth-mtls-12

To be honest, I thought that was a relatively well known aspect of TLS 1.2 (and prior) and a noted difference of the new features in TLS 1.3. Also, I'd note that we're well past WGCL for this document. But, with that said, I suppose adding some privacy considerations text on the subject is

[OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-resource-indicators-01.txt

item of the Web Authorization Protocol WG of the IETF. Title : Resource Indicators for OAuth 2.0 Authors : Brian Campbell John Bradley Hannes Tschofenig Filename: draft-ietf-oauth-resource-i

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

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 Token Exchange Authors : Michael B. Jones Anthony Nadalin Brian Campbell

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

. This draft is a 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

Re: [OAUTH-WG] late off-list developer feedback on OAuth MTLS

These changes have been made in the just published -12 draft. The diff is viewable at https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-12 Thanks all! On Sat, Oct 13, 2018 at 6:42 AM Brian Campbell wrote: > Good catch, Vladimir. Thanks! > > On Sat, Oct 13, 2018 at 2:52 AM

Re: [OAUTH-WG] late off-list developer feedback on OAuth MTLS

pad '=' characters _and_ > MUST NOT include any line breaks, whitespace, or other additional characters. > > Vladimir > > On 10/10/18 03:18, Brian Campbell wrote: > > A couple of the draft-ietf-oauth-mtls editors recived some off-list > questions and feedback from an imple

[OAUTH-WG] late off-list developer feedback on OAuth MTLS

A couple of the draft-ietf-oauth-mtls editors recived some off-list questions and feedback from an implementer, which resulted in a few small potential clarifying updates to the document that I think are worth incorporating despite the post WGLC status. Barring reasonable objections from the WG

[OAUTH-WG] missing IANA registration for ? Fwd: I-D Action: draft-ietf-oauth-device-flow-12.txt

I realize this is very late in this draft's life cycle but I just noticed it while working on something different but coincidentally similar. The device flow defines a device_code parameter to be used in the access token request to the token endpoint[1] but doesn't register it as a token request

Re: [OAUTH-WG] Link header for 401 responses

Hi Evert, The working group recently adopted a draft called Distributed OAuth that has more or less what you describe. Note that it's been adopted https://mailarchive.ietf.org/arch/msg/oauth/pziAV_EEQ9L9xeXEgtdu5s07kLM but hasn't been published as a WG document yet so, for now, is found in this

Re: [OAUTH-WG] OAuth WG meeting in Bangkok

Apologies Rifaat (& Hannes), I hadn't yet gotten around to responding to the initial request. But I would like to request time to present on the following drafts in Bangkok: https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-resource-indicators-00.txt: Error code on failure to parse resource URI

Sorry again for the slow response Vladimir, I've tried to respond inline below. On Sat, Sep 1, 2018 at 2:47 AM Vladimir Dzhuvinov wrote: > Thanks Brian. > > I assume for a request which contains multiple "resource" parameters, if > one or more of those are invalid, this should also cause an >

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-resource-indicators-00.txt

3/18 11:39 PM, internet-dra...@ietf.org wrote: > > > 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 : Resource Indicators for OAuth 2.0 >

Re: [OAUTH-WG] Last Call: (OAuth 2.0 Token Exchange) to Proposed Standard

Hi Hans, Yes, I suppose it's somewhat implicit (although the Terminology section does say that the term "client" is used as defined by RFC 6749) but the intent is that the client in a token exchange is an OAuth client

Re: [OAUTH-WG] Genart last call review of draft-ietf-oauth-token-exchange-14

Thanks for the review Jari, Regarding minimizing details, I'm thinking that incorporating some text along the lines of what's in the Privacy Considerations of RFC 7523 might be a worthwhile addition. On Fri, Aug 3, 2018 at 7:49 AM Jari Arkko

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-resource-indicators-00.txt

set of > resources that can be used in subsequent access token requests.“ > > kind regards, > Torsten. > > > Am 04.08.2018 um 05:39 schrieb internet-dra...@ietf.org: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts >

Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0"

gt; wrote: > Hi Brian, > > Am 20.07.2018 um 16:18 schrieb Brian Campbell >: > > The current draft does allow multiple "resource" parameters. However, > there seemed to be consensus in the WG meeting yesterday that only a single > "resource" parameter

Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-mtls-10

In (1), could it maybe say "normative extensions" rather than "normative changes"? Also Ping Identity is two words (rather than "PingIdentity"). Otherwise, it looks great. Thanks Rifaat! On Sat, Jul 21, 2018 at 3:25 PM, Rifaat Shekh-Yusef wrote: > All, > > The following is the shepherd

Re: [OAUTH-WG] regarding draft-ietf-oauth-jwsreq

I believe Filip is correct on these. On Sat, Jul 21, 2018 at 1:03 PM, Filip Skokan wrote: > Hello, > > about the mentioned content-types in the current draft *jwsreq-16* > > in *section-10.4.1* - says to > > check the content type of the response is "application/jose" > > > I believe this

Re: [OAUTH-WG] Call for adoption of "JWT Response for OAuth Token Introspection"

+1 On Thu, Jul 19, 2018 at 1:51 PM, William Denniss < wdenniss=40google@dmarc.ietf.org> wrote: > I support adoption of this document by the working group. > > > On Thu, Jul 19, 2018 at 10:43 AM, Rifaat Shekh-Yusef < > rifaat.i...@gmail.com> wrote: > >> Hi all, >> >> This is the call for

Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0"

on of the relationship between resource(s) and scope. >> >> Am 20.07.2018 um 08:20 schrieb n-sakimura : >> >> +1 >> >> >> >> *From:* OAuth [mailto:oauth-boun...@ietf.org ] *On >> Behalf Of *Brian Campbell >> *Sent:* Friday, July 20, 2018

Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0"

I support adoption of this document. On Thu, Jul 19, 2018 at 4:01 PM, Rifaat Shekh-Yusef wrote: > Hi all, > > This is the call for adoption of the 'Resource Indicators for OAuth 2.0' > document > following the positive call for adoption at the Montreal IETF meeting. > > Here is the document: >

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

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 : OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens Authors : Brian Campbell

Re: [OAUTH-WG] MTLS - IPR Disclosure

I am not aware of any IPR that pertains to the OAuth MTLS document. On Tue, Jul 17, 2018 at 8:07 AM, Rifaat Shekh-Yusef wrote: > Authors, > > As part of the write-up for the OAuth MTLS document, we need an IPR > disclosure from all of you.. > > Are you aware of any IPR related to the following

[OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-token-binding-07.txt

, 2018 at 12:51 PM Subject: New Version Notification for draft-ietf-oauth-token-binding-07.txt A new version of I-D, draft-ietf-oauth-token-binding-07.txt has been successfully submitted by Brian Campbell and posted to the IETF repository. Name: draft-ietf-oauth-token-binding Revision

Re: [OAUTH-WG] Dynamic Scopes

In my own personal and humble opinion, Torsten, what you describe as "(1) Parameter is part of the scope value" is the most natural approach and works without needing changes to, or going outside of, RFC6749 The OAuth 2.0 Authorization Framework. There may be AS implementations that have made

Re: [OAUTH-WG] Meeting Invite for the OAuth WG Virtual Office Hours

I tried to join this morning but was the only one on the webex (of course, user error could be involved on my part). I didn't have much specific for the call but did want to politely ask the Chairs how the document shepherding was coming along for

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 where they might be >

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

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 somewhat slow response. I'

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

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 at 11:06 AM, Brian Campbell <

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 s

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

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,

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

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

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

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. > >

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 <bcampb...@pingidentity.com> 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 commen

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

: OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens Authors : Brian Campbell John Bradley Nat Sakimura Torsten Lodderstedt Filename: draft-ietf-o

[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

[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

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

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

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 <gffle...@aol.com> wrote: > +1 > > > On 4/23/18 3:13 PM, Brian Campbell wrote: > > I just noticed/remembered that the draft also currently defines a "cid" >

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

t; > >-- Mike > > > > *From:* OAuth <oauth-boun...@ietf.org> *On Behalf Of * Brian Campbell > *Sent:* Wednesday, April 18, 2018 8:17 AM > *To:* Torsten Lodderstedt <tors...@lodderstedt.net> > *Cc:* oauth <oau

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

tforward to add (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 <bcampb...@pingidentity.com> > wrote: > > Okay, so I retract

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

ll. > I don’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 PBKDF

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

pitfalls/> > > > > [2] http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf < > > > http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf> > > > > [3] https://tools.ietf.org/html/rfc5280 < > https://tools.ietf.org/html/ > > > rfc5280> > > > > > > > &g

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

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

ost [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, >

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

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

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

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

s. Comments 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 < > n

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

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 >

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

T as well, to > explicitly type the entire Nested JWT. > > > > -- Mike > > > > *From:* Brian Campbell <bcampb...@pingidentity.com> > *Sent:* Monday, July 17, 2017 10:53 AM > *To:* Phil Hunt (IDM) <phil.h...@oracle.com> > *Cc:

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

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 <bca

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

Lodderstedt < tors...@lodderstedt.net> wrote: > Hi Brian, > > Am 20.03.2018 um 15:37 schrieb Brian Campbell <bcampb...@pingidentity.com > >: > > +1 to what Travis said about 3.8.1 > > The text in 3.8 about Open Redirection is new in this most recent -05 > versio

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

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

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

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

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

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*: > >

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

afts directories. This draft is a 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

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

tf.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 : OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens Authors :

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

nthony Nadalin Brian Campbell John Bradley Chuck Mortimore Filename: draft-ietf-oauth-token-exchange-12.txt Pages : 33 Date: 2018-01-30 Abstract: This specification d

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 <tom.van.opp...@be.ibm.com> > *Cc:* oauth <oauth@ietf.org> > > *Subject:* Re: [OAUTH-WG] rf

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

n'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 . > > > From:Nat Sakimura <sa

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

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