Re: [OAUTH-WG] Genart last call review of draft-ietf-oauth-resource-indicators-05

Thanks for the review Stewart and my apologies for the slow response - I left on a longish summer family vacation the day before the review email hit my inbox. I've fixed the nit by using "JSON Web Token (JWT)" on that first use in the source controlled editor's xml version and it'll show up in

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

herefore simple. > > On Fri, Jul 26, 2019 at 4:47 PM Brian Campbell > wrote: > >> Nat, you suggest that the "simplest solution probably is to register the >> authorization request parameters to the JWT Claims registry." However, as >> I've attempted to ar

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

Nat, you suggest that the "simplest solution probably is to register the authorization request parameters to the JWT Claims registry." However, as I've attempted to articulate several times this week ( https://mailarchive.ietf.org/arch/msg/oauth/0EenxmThjII52SAr9atpBStRtcs and muliple comments on

Re: [OAUTH-WG] Secdir last call review of draft-ietf-oauth-mtls-15

Thanks Vincent, I've fixed the nit in the source controlled editor's xml version and it'll show up in the next draft revision. On Thu, Jul 25, 2019 at 3:06 PM Vincent Roca via Datatracker < nore...@ietf.org> wrote: > Reviewer: Vincent Roca > Review result: Ready > > Hello, > > I have reviewed

Re: [OAUTH-WG] Guidance for which key to use for JWE encryption? (draft-ietf-oauth-jwsreq-19)

I'd say this one->* any "enc" key published by the AS on its jwks_uri? On Thu, Jul 25, 2019 at 3:50 PM Танги Ле Пенс wrote: > Dear all, > > draft-ietf-oauth-jwsreq-19 gives guidance on which key use to verify a > JWS' signature (the client's key) >

Re: [OAUTH-WG] a token review of draft-ietf-oauth-access-token-jwt-01/-02

You're welcome, of course. And thanks for the prompt response. I've endeavored to continue the parts of the conversation that needed continuing below. On Wed, Jul 24, 2019 at 3:46 PM Vittorio Bertocci wrote: > Thank you Brian for the thorough and insightful review! > Comments: > > > On

[OAUTH-WG] a token review of draft-ietf-oauth-access-token-jwt-01/-02

tter grouping/formatting. I'm thinking along the lines of what is done here https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-18#section-7.4.1, which you can corice xml2rfc into doing with and as in the src at https://github.com/oauth-token-exchange/spec/blob/master/draft-ietf-oauth-token

[OAUTH-WG] oauth-jwsreq & parameter registration

In the WG meeting yesterday I mentioned that I thought there might have had been some action already taken with respect to "JWT Secured Authorization Request (JAR)" and the potential name conflicts between authorization parameters and JWT claims. I tracked down this ticket in the OpenID Connect

Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02

On Mon, Jul 22, 2019 at 7:31 AM Torsten Lodderstedt wrote: > > 2) Regarding architectures: I think this BCP should focus on > recommendations for securely implementing OAuth in the different potential > architecture. I don’t think we should get into the business of recommending > and assessing

Re: [OAUTH-WG] little nit on draft-ietf-oauth-security-topics-13 wrt ietf-oauth-mtls

://tools.ietf.org/html/rfc8414 : OAuth 2.0 Authorization Server Metadata On Tue, Jul 23, 2019 at 5:19 AM Daniel Fett wrote: > Thanks Brian, I committed a fix for this. > > -Daniel > > Am 22.07.19 um 20:36 schrieb Brian Campbell: > > The description of I-D.ietf-oauth-mtls in >

[OAUTH-WG] little nit on draft-ietf-oauth-security-topics-13 wrt ietf-oauth-mtls

The description of I-D.ietf-oauth-mtls in https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.8..1.2 talks about binding to and checking against the fingerprint of the public key from the client certificate. However, https://tools.ietf.org/html/draft-ietf-oauth-mtls-15 uses a

Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02

tually addressed all your comments. On Mon, Jul 22, 2019 at 7:11 AM Roman Danyliw wrote: > Hi Brian! > > > > *From:* Brian Campbell [mailto:bcampb...@pingidentity.com] > *Sent:* Monday, July 22, 2019 8:37 AM > *To:* Roman Danyliw > *Cc:* oauth@ietf.org > *Subject:*

Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02

ent services." On Sun, Jul 21, 2019 at 4:53 PM Roman Danyliw wrote: > Hi Brian! > > > > Thanks for the update in -03. The item below is the only thing that > remains outstanding. > > > > Thanks, > > Roman > > > > > > *From:* Roman D

Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-token-exchange-18: (with COMMENT)

That works for me. On Sat, Jul 20, 2019 at 10:28 PM Benjamin Kaduk wrote: > On Fri, Jul 19, 2019 at 10:05:57AM -0600, Brian Campbell wrote: > > On Fri, Jul 19, 2019 at 8:31 AM Barry Leiba > wrote: > > > > > > > > >> — Section 1.1 — > > > >

Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02

> > > > Per Section 4.2 > >This specification updates the following error in the IANA "OAuth > >Extensions Error Registry" [IANA.OAuth.Parameters] established by > >[RFC6749]. > > > >o Error name: invalid_target > >o

Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-token-exchange-18: (with COMMENT)

On Fri, Jul 19, 2019 at 8:31 AM Barry Leiba wrote: > >> and I trust the authors and responsible AD to do the right thing. > > > > I always endeavor to do the right thing. > > You do; hence, the trust. :-) > I do appreciate that, thank you. > And thanks for the quick responses. > I try. To

Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-token-exchange-18: (with COMMENT)

Barry, thanks for the review, ballot position and comments. Please see inline below for my replies to the latter. On Thu, Jul 18, 2019 at 3:06 PM Barry Leiba via Datatracker < nore...@ietf.org> wrote: > Barry Leiba has entered the following ballot position for >

Re: [OAUTH-WG] IETF105 OAuth WG Draft Agenda

I'd also be interested. On Wed, Jul 17, 2019 at 12:47 PM Mike Jones wrote: > I’d be interested in hearing that presentation – particularly the > “lessons” part. > > > >-- Mike > > > > *From:* OAuth *On Behalf Of * Richard Backman, >

Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02

Yeah, as you surmised, there is some history behind this. Basically draft-ietf-oauth-token-exchange predates draft-ietf-oauth-resource-indicators by a good long time (years) and with the hope and expectation that draft-ietf-oauth-token-exchange would move to RFC, I've avoided having a reference in

Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02

Thank you, Roman, for the review. Some replies are inline below. I'll aim to push out a -03 addressing this stuff sometime not too long after the I-D submission embargo is lifted next week. On Tue, Jul 16, 2019 at 5:23 PM Roman Danyliw wrote: > Hi! > > The following is my AD review of

Re: [OAUTH-WG] Benjamin Kaduk's Yes on draft-ietf-oauth-token-exchange-17: (with COMMENT)

issue, should it ever prove to be an issue (which I kinda don't think will happen anyway). On Fri, Jul 12, 2019 at 7:13 PM Benjamin Kaduk wrote: > On Sun, Jul 07, 2019 at 09:32:15AM -0400, Brian Campbell wrote: > > On Sat, Jul 6, 2019 at 2:42 PM Benjamin Kaduk wrote: > > > >

Re: [OAUTH-WG] Benjamin Kaduk's Yes on draft-ietf-oauth-token-exchange-17: (with COMMENT)

On Sat, Jul 6, 2019 at 2:42 PM Benjamin Kaduk wrote: > > > Not to my recollection. I'm honestly not even sure what an array would > mean > > for "may_act". Do you mean for "act"? > > Currently we can say that ad...@example.com "may act" as u...@example.com.. > But IIUC we don't have a way to say

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

-17 https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-17. As such, I'd respectfully request that you review the changes and clear the discuss. Thank you, Brian On Wed, Nov 28, 2018 at 8:19 AM Brian Campbell wrote: > Thank you for the review, Adam. I do sincerely hope that your time with &

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

https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-17 with changes that believe (or hope anyway) address all of your comments. As such, I'd respectfully request that you review the changes and clear the discuss. Thank you, Brian On Sat, Jan 19, 2019 at 8:58 AM Brian Campbell wrote

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

On Wed, Nov 28, 2018 at 1:38 PM Brian Campbell wrote: > 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/MKqEIs

Re: [OAUTH-WG] Second AD Review: draft-ietf-oauth-mtls

Okay, -15 has been published and incorporates those fixes and suggestions: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-15 On Mon, Jun 24, 2019 at 5:04 PM Brian Campbell wrote: > Thanks Roman, I'll work to incorporate those suggestions into the next > revision before the impen

Re: [OAUTH-WG] Second AD Review: draft-ietf-oauth-mtls

Thanks Roman, I'll work to incorporate those suggestions into the next revision before the impending I-D submission cutoff date. On Mon, Jun 24, 2019 at 2:14 PM Roman Danyliw wrote: > Hi Brian! > > > > My response is inline ... > > > > *From:* Brian Campbell [mailto

Re: [OAUTH-WG] Second AD Review: draft-ietf-oauth-mtls

Thanks for the additional review, Roman. I feel lucky, it's not often one gets *two* AD reviews :) Please see below for replies inline with a few followup questions. On Sat, Jun 22, 2019 at 12:29 PM Roman Danyliw wrote: > Hi! > > I conducted as second AD review of draft-ietf-oauth-mtls per

Re: [OAUTH-WG] Client assertions to endpoints other than the token endpoint

Yeah, the discussion was/is definitely about "other endpoints at the AS" like revocation, introspection, device authorization, etc. On Fri, May 31, 2019 at 12:47 PM George Fletcher wrote: > So if by "other endpoints" we mean "other endpoints at the AS" then I > think issuer makes a lot of sense

Re: [OAUTH-WG] OAuth WG Sessions in Montreal

Please allow some time for presentation and discussion of DPoP. https://tools.ietf.org/html/draft-fett-oauth-dpop-01 is the latest draft but I hope and expect that there will be an update before Montreal. On Mon, May 27, 2019 at 3:04 PM Rifaat Shekh-Yusef wrote: > All, > > Please, let us know

Re: [OAUTH-WG] MTLS vs. DPOP

Practically speaking there's the MTLS draft, which has been sent to the IESG for publication, has commercial and opensource implementations as well as production deployments, and is referenced by other prospective standards and profiles. It's not uncommon to receive off list inquires about the

Re: [OAUTH-WG] Token Exchange status and Resource Indicators

On Tue, May 7, 2019 at 7:03 AM Hannes Tschofenig wrote: > > The group can define what is in scope of a document and what isn't. > Which is what's been done with the document during the course of it's development and WGLC and subsequent submission to the IESG for publication. --

Re: [OAUTH-WG] Token Exchange status and Resource Indicators

On Fri, May 3, 2019 at 9:39 AM Emond Papegaaij wrote: > [...] we are investigating 'OAuth 2.0 > Token Exchange'. [...] However, I noticed that > draft 16 has expired on April 22, 2019. Is this specification still active? > Yeah, it is. A nontrivial amount of stuff came up in IESG balloting on

Re: [OAUTH-WG] draft-fett-oauth-dpop-01 implementation feedback

On Thu, May 2, 2019 at 12:33 AM Paul Querna wrote: > Overall the spec felt functional, though I think the biggest gaps for > a deployment are with the Access Token interactions, but this makes > sense since that seems to be addressed in the future by >

Re: [OAUTH-WG] Transaction Authorization with OAuth

On Tue, Apr 30, 2019 at 5:03 AM Torsten Lodderstedt wrote: > > > > On 26. Apr 2019, at 19:57, Brian Campbell > wrote: > > > > One thing that I think is missing from the article in the discussion of > pros and cons is that in many cases a large or even voluminous

Re: [OAUTH-WG] How to deal with multi-valued request parameters in a JAR (draft-ietf-oauth-jwsreq-17)?

t; not. > > It's unfortunately not clear to what the third applies, but BECAUSE it can be > understood as applying to unrecognized parameters as well, I think it SHOULD > be interpreted that way (until an errata clarifies the situation) > > > Le lun. 22 avr. 2019 17:39, Brian Campbe

Re: [OAUTH-WG] Transaction Authorization with OAuth

One thing that I think is missing from the article in the discussion of pros and cons is that in many cases a large or even voluminous request can be sent via auto submitting form post (like https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html but the other way around from client to

Re: [OAUTH-WG] How to deal with multi-valued request parameters in a JAR (draft-ietf-oauth-jwsreq-17)?

FWIW, the second paragraph of resource indicators, section 2.1 says to use a JSON array via the following text: For authorization requests sent as a JWTs, such as when using JWT Secured Authorization Request

[OAUTH-WG] draft-ietf-oauth-mtls-14

e 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 Jo

Re: [OAUTH-WG] MTLS and SAN

g a new certificate with the same subject from a trusted >certificate authority (CA). > > > > I think the listing of methods is clear enough as it is — but my problem > was that I read the above paragraph, then jumped right into the list below > for the exact fields without

Re: [OAUTH-WG] draft-fett-oauth-dpop-00

The thought/intent is that it's really about proof-of-possession rather than protecting the request. So the signature is over a minimal set of information. On Mon, Apr 8, 2019 at 5:41 PM Justin Richer wrote: > Corollary to this, are there thoughts of header protection under this > method, and

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

o provide > guidance on it more compelling, not less. There are important scenarios > where access decisions are made on the basis of that information, and > implementations WILL find a way to get the info they are interested into. > To me that's all the more reasons to provide guidance on

Re: [OAUTH-WG] MTLS and SAN

Yes, the intent is that the client be configured (dynamically or statically or however that comes to be) with one and only one expected subject, which also includes the location in the certificate that subject will be. And that is checked against at authentication time. As the writer of the

Re: [OAUTH-WG] Early IANA registration for Token Exchange Draft

The request originated from Ben Kaduk's Discuss ballot on the draft and suggestion that the URI values be registered. Some of the relevant messages in the thread: https://mailarchive.ietf.org/arch/msg/oauth/QiA5PDBsKlApNZIRy3QOttd-JDM

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

> FWIW, to me, George's suggestion "assume[ing] that the auth_time value should be updated to the latest time at which the user authenticated" though some unspecified and in many cases non-existent link between the AT and a current user session at the AS is an example of how aut

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

rted > > Hans. > > On Thu, Apr 4, 2019 at 5:27 PM Brian Campbell 40pingidentity@dmarc.ietf.org> wrote: > >> The same is true for most of the other main claims too - iss, exp, aud, >> sub, iat, etc.. They are defined in RFC 7519 not OIDC. >> >> On Thu, Apr 4

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

The same is true for most of the other main claims too - iss, exp, aud, sub, iat, etc.. They are defined in RFC 7519 not OIDC. On Thu, Apr 4, 2019 at 9:21 AM Brian Campbell wrote: > Yeah, OpenID.Core isn't the right reference for `aud`. > https://tools.ietf.org/html/rfc7519#section

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

rent enough to prevent developers from reusing >code and skills when moving from product to product. >- I asked several individuals from key products and services to share >with me concrete examples of their JWT access tokens (THANK YOU Dominick >Baier (IdentityServer

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

dressed by those solutions >are mostly the same across vendors, but the syntax and interpretations in >the implementations are different enough to prevent developers from reusing >code and skills when moving from product to product. >- I asked several individuals from key

Re: [OAUTH-WG] draft-fett-oauth-dpop-00

Except that the jwk header is more appropriate in the given context https://tools.ietf.org/html/rfc7515#section-4.1.3 - it is the public key that corresponds to the key used to digitally sign the JWS. Which is what it is. On Thu, Mar 28, 2019, 6:32 AM Mike Jones wrote: > Good observation,

Re: [OAUTH-WG] Mentioning refresh tokens in MTLS' abstract

PM Neil Madden wrote: > Comments in-line: > > On 14 Mar 2019, at 18:50, Brian Campbell > wrote: > > Certificate-binding refresh tokens issued to *public clients* (those that > don't have authentication credentials established with the AS, a.k.a. > clients configured or r

Re: [OAUTH-WG] Mentioning refresh tokens in MTLS' abstract

he refresh token is > bound to the original certificate, then this would be ruled out (the new > certificate would be rejected) and certificate rotation becomes impossible > in all cases. Am I missing something? > > — Neil > > > On 14 Mar 2019, at 12:28, Brian Camp

Re: [OAUTH-WG] Mentioning refresh tokens in MTLS' abstract

clients using "none"?) to > authenticate the tls_client_certificate_bound_access_tokens client metadata > property also conditions binding the refresh token. At the cost of the RT > being unusable if the client loses or rotates the certificate. > > Best, > *Filip* >

Re: [OAUTH-WG] Draft Agenda for IETF104 OAuth WG meetings

There are icon links for audio and video next to the sessions on the agenda at https://datatracker.ietf.org/meeting/104/agenda/. I believe registration is required (but is free for remote participants). See https://www.ietf.org/how/meetings/104/remote/ for more official information. Recordings

Re: [OAUTH-WG] Mentioning refresh tokens in MTLS' abstract

Now the normative language is SHOULD therefore disallowing cert rotation.. >> Or am I missing something? >> >> S pozdravem, >> *Filip Skokan* >> >> >> On Thu, 14 Mar 2019 at 00:21, Brian Campbell > 40pingidentity@dmarc.ietf.org> wrote: >> >&

Re: [OAUTH-WG] Mentioning refresh tokens in MTLS' abstract

As I kinda said on that call, I understand the ask and I do think it'd be reasonable to mention refresh tokens in the abstract now that the document does describe binding refresh tokens to the client certificate with public clients. I'm struggling to see the fix as pretty easy, however, given the

Re: [OAUTH-WG] Client authentication in the Device Authorization Request

All sounds good to me. Thanks again for picking this one up quickly. On Mon, Mar 11, 2019 at 2:43 PM William Denniss wrote: > > > On Mon, Mar 11, 2019 at 1:21 PM Brian Campbell 40pingidentity@dmarc.ietf.org> wrote: > >> And thank you, William, for being responsive abou

Re: [OAUTH-WG] Client authentication in the Device Authorization Request

AM, George Fletcher < >> gffletch=40aol@dmarc.ietf.org> wrote: >> >> +1 >> >> to using the same client authn method as for the /token endpoint >> >> On 3/11/19 12:31 PM, Brian Campbell wrote: >> >> >> >> On Mon, Mar 11, 2019

Re: [OAUTH-WG] Client authentication in the Device Authorization Request

ine with the >> late draft implementations. Wdyt? >> >> S pozdravem, >> *Filip Skokan* >> >> >> On Mon, 11 Mar 2019 at 17:08, Brian Campbell > 40pingidentity@dmarc.ietf.org> wrote: >> >>> I do realize it's very late in the process f

Re: [OAUTH-WG] Client authentication in the Device Authorization Request

I do realize it's very late in the process for this document but believe these omissions can be addressed in the document with only minor changes/additions and that it'd be better late than not at all. On Mon, Mar 11, 2019 at 10:03 AM Brian Campbell wrote: > Another omission[1] (maybe

[OAUTH-WG] Client authentication in the Device Authorization Request

Another omission[1] (maybe, I believe it is anyway) to the Device Flow is that client authentication isn't defined for the device authorization request to device authorization endpoint. I suspect that it's largely an oversight because public clients are really the conical use-case for the device

Re: [OAUTH-WG] OAuth 2.0 Device flow error response

While probably not terribly important from an interoperability perspective, I agree that does seem like an omission. I took a quick look at our implementation and bad requests to the device authorization endpoint will indeed return what is a standard OAuth 2.0 error response normally from the

Re: [OAUTH-WG] draft-ietf-oauth-resource-indicators-02

It's not uncommon for a resource server (or API or protected resource) to have a client id established with the AS. Typically that's used in the context of the resource server acting as a client (and authenticating with the AS) when calling the AS for access token introspection. Using that id as

Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-02

Thanks Rifaat, It looks okay to me. I went ahead and fixed the nits in the document source too: https://github.com/ietf-oauth-resource-indicators/i-d/commit/e967f667a0224953683833b704f5cc59ce48f96d On Tue, Feb 26, 2019 at 6:29 AM Rifaat Shekh-Yusef wrote: > All, > > The following is the

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

of any IPR related to the following Resource Indicators > document? > https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02 > > Regards, > Rifaat > > > On Mon, Jan 7, 2019 at 8:01 AM Brian Campbell > wrote: > >> I am not aware of any IPR related

Re: [OAUTH-WG] MTLS endpoints & discovery (was something else)

The objective is to allow the AS to provide MTLS negotiating endpoints on a different host and/or port so that any non-desirable side effects of requesting client certificates during the TLS handshake can be avoided for 'regular' clients that are not doing any MTLS. In all likelihood, I'd expect

Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token endoint & discovery

In the upcoming revision of the draft I've reworked and moved that section [1] so that it is more focused on public clients and certificate bound tokens (see [a]). But yes, I think it comes down to saying that a client that is expecting to use MTLS (for whatever reason: bound tokens or client auth

Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token endoint & discovery

d require more > complex code to work with. But that’s just my experience as, you know, an > actual developer. > > > > Let’s keep the assumptions and snide remarks about others’ backgrounds off > the list, please. > > > > -- > > Annabelle Richard Backman >

Re: [OAUTH-WG] MTLS token endoint & discovery

place. > Essentially, what happens when an attacker crafts a document that says the > MTLS token endpoint is theirs and the regular token endpoint is legit, or > vice versa? > > — Justin > > On Feb 11, 2019, at 7:26 AM, Brian Campbell < > bcampbell=40pingidentit

Re: [OAUTH-WG] MTLS token endoint & discovery

t’s a reasonable and pragmatic option. > > Thanks > ——— > Dominick > > On 11. February 2019 at 13:26:37, Brian Campbell ( > bcampb...@pingidentity.com) wrote: > > It's been pointed out that the potential issue is not isolated to the just > token endpoint but that revo

Re: [OAUTH-WG] [Ace] Resource, Audience, and req_aud

like a distinction worth making when I wrote that last week. On Sat, Feb 9, 2019 at 3:31 PM Benjamin Kaduk wrote: > On Thu, Feb 07, 2019 at 02:28:02PM -0700, Brian Campbell wrote: > > > > The token-exchange draft defines both the "resource" and "audience" &g

Re: [OAUTH-WG] MTLS token endoint & discovery

tives or additional measures. And also some vocal opposition to it. On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier wrote: > We are currently implementing MTLS in IdentityServer. > > Our approach will be that we’ll offer a separate token endpoint that > supports client certs. Ar

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

a good > reminder that even a seemingly innocuous change that should be backwards > compatible can force more work on clients than we expect. > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *Brian Campbell > *Da

Re: [OAUTH-WG] [Ace] Resource, Audience, and req_aud

For better or worse there is a long and winding road that has led to where we are now with these parameters. And there has been plenty of misunderstanding, miscommunication, dysfunction, questionable decisions, and general SDO process along the way that/'s helped get to this point. I've certainly

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

:15 PM Brian Campbell wrote: > "far" should have said "fair" in the previous message > > > > > > On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell > wrote: > >> It may well be due to my own intellectual shortcomings but these >> issues/qu

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

"far" should have said "fair" in the previous message On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell wrote: > It may well be due to my own intellectual shortcomings but these > issues/questions/confusion-points are not resonating for me as being > problematic

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

Hybrids”) and get mTLS out the door. > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *OAuth on behalf of Brian Campbell > > *Date: *Monday, February 4, 2019 at 5:28 AM > *To: *"Richard Backman, Annabelle

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

endpoint in perpetuity for all cases. I > don’t think that is appropriate (in the general case) for an endpoint with > request processing business logic behind it, since that logic may change > over time. > >> > >> -DW > >> > >>> On Feb 4, 2019, at 6:28 AM,

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

an AS wants to support both, and is > unambiguous in its behavior and meaning. > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *Brian Campbell > *Date: *Friday, February 1, 2019 at 3:17 PM > *To: *"Richard Backman,

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

tunities for confusion and failure that do not exist > now, and forces them on everyone who supports mTLS. In contrast, the 307 > redirect is only required when an AS wants to support both, and is > unambiguous in its behavior and meaning. > > > > -- > > Annabelle Ri

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

ight—we need a > parameter. > > Phil > > Oracle Corporation, Cloud Security and Identity Architect > @independentid > www.independentid.com > phil.h...@oracle.com > > On Feb 1, 2019, at 1:43 PM, Brian Campbell > wrote: > > I guess I'm not clear what you are driving a

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

> -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *OAuth on behalf of Brian Campbell > > *Date: *Friday, February 1, 2019 at 1:31 PM > *To: *George Fletcher > *Cc: *oauth > *Subject: *Re: [OAUTH-WG] MTLS and in-browser clie

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

mobile) because the client will decide to use MTLS. With browsers, > they only use it if forced. > > Phil > > Oracle Corporation, Cloud Security and Identity Architect > @independentid > www.independentid.com > phil.h...@oracle.com > > On Feb 1, 2019, at 1:14 PM, Brian Campbe

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

Yes, that would work. On Fri, Feb 1, 2019 at 2:28 PM George Fletcher wrote: > What if the AS wants to ONLY support MTLS connections. Does it not specify > the optional "mtls_endpoints" and just use the normal metadata values? > > On 1/15/19 8:48 AM, Brian Campbell wrote: &

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

ke they have to > hit an mtls required endpoint before they reliably use a client cert. > > Phil > > On Feb 1, 2019, at 12:56 PM, Brian Campbell > wrote: > > It would be more a client having reached a non-MTLS endpoint and is 307'd > to an MTLS enabled endpoint. >

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

.com > > On Feb 1, 2019, at 11:56 AM, Brian Campbell < > bcampbell=40pingidentity@dmarc.ietf.org> wrote: > > I'm finally getting around to working on the document updates (there's > quite a few things that came out of AD review too). As far as the issue in > this thread goes

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

'd be more of a considerations type text. On Wed, Jan 16, 2019 at 5:52 AM Brian Campbell wrote: > I guess I should have also said or been more straightforward in saying > that I don't particularly want to try and discuss/define the use of a 307 > in the document. > > On Tue, Jan

Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

tration and won’t > realize that it’s coming from a different universe. If we can harmonize > things now, we should. > > > > -- Mike > > > > *From:* OAuth *On Behalf Of *George Fletcher > *Sent:* Monday, Ja

Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

t >> in principle, as long as we leave nothing as exercise to the reader and we >> are very clear on usage (e.g. mutual exclusivity, etc) but didn't have a >> chance to speak w Brian about it. If the discussion stretches further, I >> would suggest we pause it and let him enjoy his

Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

gt; >>> >>> Note that the ACE WG is proposing to register a logical audience >>> parameter “req_aud” in >>> https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 - partly >>> based on feedback from OAuth WG members. This is a general OAuth >>> p

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

n a the family I > was away from email for quite some time. > > On Tue, Dec 04, 2018 at 02:54:36PM -0700, Brian Campbell wrote: > > 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

Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

Thanks Rifaat. Process is as process does, right? I do kinda want to grumble about WGCL having passed already but that's mostly because replying to these kinds of threads is hard for me and I'll just get over it... As far as I understand things, the security concerns come into play when the

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

code to be followed. > > S pozdravem, > *Filip Skokan* > > > On Tue, Jan 15, 2019 at 2:54 PM Brian Campbell > wrote: > >> I don't know that the use of 307 would need to be discussed in the >> document itself. >> >> On Tue, Jan 15, 2019 at

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

ndle it appropriately. >> There would probably need to be an error defined for clients who attempt >> to use `tls_client_auth` at the regular endpoint. >> >> Dave >> >> On Mon, 14 Jan 2019 at 22:29, Brian Campbell > 40pingidentity@dmarc.ietf.org>

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

It would definitely be optional, apologies if that wasn't made clear. It'd be something to the effect of optional for the AS to include and clients doing MTLS would use it when present in AS metadata. On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge wrote: > I'm in favour of the `mtls_endpoints`

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

requests based on the calling client and the likelihood that some/all OAuth client software would handle it appropriately. On Fri, Jan 11, 2019 at 12:32 PM David Waite wrote: > > > > On Jan 11, 2019, at 3:32 AM, Neil Madden > wrote: > > > > On 9 Jan 2019, at 05:

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

No, my testing was not via XHR/fetch. Just direct request from the browser. I was making the assumption (maybe foolishly) that it wouldn't impact behavior because it's all at the network layer. I saw that Firefox setting but left the default (at least for my install), which was not to autopick.

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

ant-type:token-exchange. > > -- Mike > > -Original Message- > From: Benjamin Kaduk > Sent: Friday, January 11, 2019 8:13 AM > To: Brian Campbell > Cc: The IESG ; oauth ; > draft-ietf-oauth-token-excha...@ietf.org; oauth-cha...@iet

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

d for a cert. Right? > > — Neil > > On 7 Jan 2019, at 17:21, Brian Campbell > wrote: > > I don't honestly know for sure but I suspect that employees of big > corporations will likely have keys/certs on their devices/machines that are > issued by some internal C

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

that itself could have any of the same endpoint names in it would be the most straight forward way to approach that. Best, > *Filip* > > > On Mon, Jan 7, 2019 at 6:22 PM Brian Campbell 40pingidentity@dmarc.ietf.org> wrote: > >> I don't honestly know for sure but I sus

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