Re: [OAUTH-WG] WGLC for draft-ietf-oauth-token-exchange-08

Speaking as an individual, for a number of reasons, I do not believe that any of the additional comments or suggestions should be incorporated into the document. As a document editor working within the IETF processes, my aim is for the document to reflect the (rough) consensus of this Working Grou

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

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

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

2.0 Token Binding Authors : Michael B. Jones John Bradley Brian Campbell William Denniss Filename: draft-ietf-oauth-token-binding-04.txt Pages : 27 Date

Re: [OAUTH-WG] WGLC for draft-ietf-oauth-token-exchange-08

Okay, thanks Rifaat. I'll make those changes. On Jun 30, 2017 3:59 PM, "Rifaat Shekh-Yusef" wrote: > Thanks Brian. > > See my replies inline... > > > On Fri, Jun 30, 2017 at 4:08 PM, Brian Campbell < > bcampb...@pingidentity.com> wrote: > >>

Re: [OAUTH-WG] WGLC for draft-ietf-oauth-token-exchange-08

Thanks for the review, Denis. And I apologize for the slow reply - I've had a lot of different things on my plate recently. And, quite frankly, I was sort of hoping one of the co-authors on the document might respond to your comments. But hope only goes so far. So replies are inline below... On Mo

Re: [OAUTH-WG] WGLC for draft-ietf-oauth-token-exchange-08

Thanks for the review, Rifaat. Replies are inline below... On Mon, Jun 26, 2017 at 6:40 AM, Rifaat Shekh-Yusef wrote: > Hi (as individual), > > I have reviewed this version of the document and I have the following > comments/questions: > > > Section 2.1, page 8, last paragraph: > >"In the a

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

: 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 of the IETF. Title : Mutual TLS Profile for OAuth 2.0 Authors : Brian Campbell John

Re: [OAUTH-WG] Agenda requests for Prague

gt; -- <https://www.pingidentity.com>[image: Ping Identity] <https://www.pingidentity.com> Brian Campbell Distinguished Engineer bcampb...@pingidentity.com w: +1 720.317.2061 c: +1 303.918.9415 Connect with us: [image: Glassdoor logo] <https://www.glassdoor.com/Overview/Working-at-P

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

Token Binding for Refresh Tokens".* "the" should be removed from > "the of PKCS is". > > Best Regards, > Takahiko Kawasaki > > > > 2017-03-28 1:32 GMT+09:00 Brian Campbell : > >> -03 only fixes a few mistakes in and around the exam

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

the that certificate matches ..." should be removed (= that part should be > "... verify that the certificate matches ..."). Is it enough to mention it > in this mailing list like this? > > Best Regards, > Takahiko Kawasaki > > 2017-05-27 5:34 GMT+09:00 Brian Campb

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

08 of the draft? > We would like to start a WGLC on the new version. > > Regards, > Rifaat > > > On Fri, May 26, 2017 at 6:21 PM, Brian Campbell < > bcampb...@pingidentity.com> wrote: > >> Following up on this, I'd like to propose a different and less invas

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

point I believe the document will be ready for WGLC. actor_token OPTIONAL. A security token that represents the identity of the acting party. Typically this will be the party that is authorized to use the requested security token and act on behalf of the subject. On Thu, May 11, 2017 at 9:5

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

I-D Action: draft-ietf-oauth-mtls-01.txt To: i-d-annou...@ietf.org 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 of the IETF. Title : Mutual TLS Profiles for

Re: [OAUTH-WG] Alexey Melnikov's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT)

As far as I can tell, 'NOT RECOMMENDED' is fine per RFC 2119. from https://www.ietf.org/rfc/rfc2119.txt 4. SHOULD NOT This phrase, *or the phrase "NOT RECOMMENDED"* mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even usef

Re: [OAUTH-WG] re comments on MTLS (was Re: Call for Adoption: Mutual TLS Profiles for OAuth Clients)

specific issuers one per client should be fine. > I expect that in most cases the issuer will need to be in the trust store > of the AS anyway so this is just pinning the cert to one of a limited set. > > John B. > > On May 15, 2017, at 2:42 PM, Brian Campbell > wrote: > >

Re: [OAUTH-WG] re comments on MTLS (was Re: Call for Adoption: Mutual TLS Profiles for OAuth Clients)

t; For most proof of possession we should be promoting token binding as the > most flexible approach as it also works with mobile without per instance > registration. > > John B. > > > On Apr 21, 2017, at 7:41 PM, Brian Campbell > wrote: > > Thanks, James, for the adoption suppo

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

ng issued >> token doesn't contain info about the delegation or actor. Similarly, the >> actor might not be strictly doing the impersonation but rather just be a >> party (again maybe needed for policy or auditing) to the token exchange >> event itself. When I wrote the &

Re: [OAUTH-WG] Mutual TLS Profiles for OAuth Clients

Thanks Hannes & Rifaat, draft-ietf-oauth-mtls-00 has been submitted. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-mtls-00 https://datatracker

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

ad the delegation scenario at the front of my mind and > (clearly) intended to accommodate it. However, I didn't intend to limit it > to only that and, looking at the text again, I think what is there now is > too prescriptive and narrow. Thus my proposing to generalize the text > so

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

tend to limit it to only that and, looking at the text again, I think what is there now is too prescriptive and narrow. Thus my proposing to generalize the text somewhat. On Mon, May 8, 2017 at 10:29 AM, Brian Campbell wrote: > I do have one minor issue I'd like to raise that relates

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

usef > wrote: > >> Hi All, >> >> The last email from Brian addresses the multiple audiences/resources >> issue with an error code, and we did not see any objection to this approach >> so far. >> >> >> *Authors,* >> >> Are there any other open issues w

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

his draft? > Do you believe it is ready for WGLC? > > Thanks, > Rifaat & Hannes > > > > On Fri, Mar 31, 2017 at 11:03 AM, Brian Campbell < > bcampb...@pingidentity.com> wrote: > >> As mentioned during the Chicago meeting the "invalid_target&quo

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-13.txt

rameters/oauth-parameters.xhtml#parameters because the parameter names and claim names collide when using a JWT Secured Authorization Request. On Tue, Apr 4, 2017 at 9:41 AM, Nat Sakimura wrote: > Thanks Brian for spotting these. I will make the corrections in -14. > > Best, > > N

[OAUTH-WG] re comments on MTLS (was Re: Call for Adoption: Mutual TLS Profiles for OAuth Clients)

Thanks, James, for the adoption support as well as the review and comments. I've tried to respond to the comments inline below. On Thu, Apr 20, 2017 at 11:33 PM, Manger, James < james.h.man...@team.telstra.com> wrote: > I support adoption of draft-campbell-oauth-mtls. > > Now some comments on the

Re: [OAUTH-WG] Call for Adoption: Mutual TLS Profiles for OAuth Clients

I accept adoption of this document as a starting point for work in the OAuth working group! On Thu, Apr 20, 2017 at 10:32 AM, Hannes Tschofenig < hannes.tschofe...@gmx.net> wrote: > Hi all, > > based on the strong support for this document at the Chicago IETF > meeting we are issuing a call for a

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

01.txt has been successfully submitted by Brian Campbell and posted to the IETF repository. Name: draft-campbell-oauth-mtls Revision: 01 Title: Mutual TLS Profiles for OAuth Clients Document date: 2017-04-10 Group: Individual Submission Pages:

Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-mtls-00.txt

ozkin > wrote: > >> Hi Brian >> >> Thanks, a minor typo in the example, >> "x5t#s256" as opposed to "x5t#S256" >> >> (sorry if it was already reported, might've missed it) >> >> Cheers, Sergey >> On 30/03/17 22:15, Br

Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-mtls-00.txt

Hi Dave, Thanks for the review, support, and feedback. I've already removed the extraneous "can" in the source. The easy part... I did struggle with terminology for many of the reasons you point out about there being somewhat established terms that aren't quite the same as those defined in the R

[OAUTH-WG] Fwd: Token Binding Demo Online

Below is the Token Binding demo that I mentioned and said I share on the list during the Friday meeting in Chicago. -- Forwarded message -- From: Brian Campbell Date: Fri, Mar 24, 2017 at 3:11 PM Subject: Token Binding Demo Online To: IETF Tokbind WG I put up a demonstration

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

for resources. >> >> >> >>Thanks, >> >> -- Mike >> >> >> >> *From:* OAuth [mailto:oauth-boun...@ietf.org ] *On >> Behalf Of *Brian Campbell >> *Sent:*

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-13.txt

and a typo - "If thie location is" should say "If this location is" On Fri, Mar 31, 2017 at 8:37 AM, Brian Campbell wrote: > BTW, the intro still has text about 'dynamic parameters such as "state"' > that need to be cleaned up. https://tools.ietf.

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-13.txt

BTW, the intro still has text about 'dynamic parameters such as "state"' that need to be cleaned up. https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-13#section-1 On Fri, Mar 31, 2017 at 8:36 AM, Brian Campbell wrote: > "The current text causes the AS to ignore

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-13.txt

"The current text causes the AS to ignore them and not return a error. " - except that I don't believe the current text actually specifies that anywhere. And I think that the intent of Mike's original comment was that -13 doesn't specify the behavior but that it needs to be revised to do so. I'd s

[OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-mtls-00.txt

t;. I apologize for the 11th hour publication but hope some folks will have a chance to read it. -- Forwarded message -- From: Date: Thu, Mar 30, 2017 at 3:49 PM Subject: New Version Notification for draft-campbell-oauth-mtls-00.txt To: Brian Campbell , Nat Sakimura < n-sa

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

John Bradley Brian Campbell William Denniss Filename: draft-ietf-oauth-token-binding-03.txt Pages : 26 Date: 2017-03-27 Abstract: This specification enables OAuth 2.0 implementations to

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

d suggest to drop support for multiple audience and > resource parameters and make audience and resource mutual exclusive. I > think this is sufficient and much easier to implement. > > kind regards, > Torsten. > > > Am 11.01.2017 um 20:04 schrieb Brian Campbell >: > > Dr

Re: [OAUTH-WG] oauth - Requested sessions have been scheduled for IETF 98

ken-exchange) - Mike > Jones - 15 minutes > OAuth Authorization Server Metadata (draft-ietf-oauth-discovery) - > Mike Jones - 15 minutes > > I'd also talked with Brian Campbell and I think he wants to lead this > discussion, in part based on his implementation exper

Re: [OAUTH-WG] Token Binding Presentations?

Dirk gave this preso nearly 2 years ago https://www.slideshare.net/ CloudIDSummit/cis-2015-intro-to-token-binding-over-http-cis-2015 which is out of date but has the main concepts, I think. There's also this http://www.browserauth.net/token-binding page by him. I'm planing on a doing a presentatio

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

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

Re: [OAUTH-WG] Device Code expiration and syntax

On Sat, Mar 11, 2017 at 1:54 PM, William Denniss wrote: > > On Sat, Mar 11, 2017 at 12:40 PM, Justin Richer wrote: > >> >> >> Secondly, I had a question about the “response_type” parameter to the >>> device endpoint. This parameter is required and it has a single, required >>> value, with no reg

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

Two little nits about endpoint naming: Section 2 defines "device endpoint", which is used in the document everywhere except the new metadata sections (section 4

Re: [OAUTH-WG] [oauth-token-exchange] Composite Token Design

Hi Jan, I don't think you're missing anything. However, the use of the 'act' claim to identify the delegate and convey that delegation is happening was an intentional decision. While delegation is a security sensitive thing, it often occurs as impersonation with no explicit indication about delega

Re: [OAUTH-WG] Pushing "OAuth 2.0 for Native Apps" to the IESG -- Short Working Group Last Call

-07 LGTM On Feb 20, 2017 2:53 AM, "Hannes Tschofenig" wrote: > Hi all, > > after the working group last call of the "OAuth 2.0 for Native Apps" > document July last year (see > https://www.ietf.org/mail-archive/web/oauth/current/msg16534.html) I > had, as a shepherd, collected IPR confirmations

Re: [OAUTH-WG] draft-ietf-oauth-token-binding-01

Adding some examples would probably be helpful, yes. Thanks. Some will maybe be more possible/sensible than others (like I don't know what exactly to show in an example of binding a refresh token) but I'll endeavor to add some useful examples in a future revision. On Tue, Feb 21, 2017 at 1:36 AM,

Re: [OAUTH-WG] Call for adoption: OAuth Security Topics

+ 1 On Thu, Feb 2, 2017 at 12:49 PM, Justin Richer wrote: > +1, it's a good topic and this document is a good starting point. > > -- Justin > > On 2/2/2017 2:09 AM, Hannes Tschofenig wrote: > > Hi all, > > this is the call for adoption of the 'OAuth Security Topics' document > following the pos

Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app

+1 to the AppAuth pattern On Wed, Jan 25, 2017 at 12:48 PM, wrote: > There are a number of patterns that people use. > > > > I prefer the AppAuth pattern where the native app is a OAuth client to > your server and you are protecting your API with OAuth. Your AS becomes a > Connect/SAML/Twitter

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

s. This draft is a work item of the Web Authorization Protocol of the IETF. Title : OAuth 2.0 Token Exchange Authors : Michael B. Jones Anthony Nadalin Brian Campbell John Bradley

Re: [OAUTH-WG] draft-campbell-oauth-tls-client-auth-00 feedback

inline... On Wed, Nov 16, 2016 at 1:47 AM, Sean Leonard wrote: > Hello OAuth folks: > > I have some feedback about draft-campbell-oauth-tls-client-auth-00. > Overall I think it is a good, concise effort, and should be adopted as a WG > item. Sorry that it didn’t get addressed in the WG meeting.

Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

Whoops, "about" at the end of the 1st paragraph should be "abort". On Nov 16, 2016 8:08 AM, "Brian Campbell" wrote: > Yes, I believe you are correct. Client certificates are provided in the > handshake (initial or renegotiated) at the request of the server.

Re: [OAUTH-WG] About Big Brother and draft-campbell-oauth-resource-indicators-00

utes from the first > session, in particular: > > Brian Campbell and John did a draft allowing the client to tell the AS > where it plans to use the token > draft-campbell-oauth-resource-indicators > > This enables the AS to audience restrict the access token to >

Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

FC7591 defines a client model >> where RFC6749 didn’t. Ideally all that metadata would’ve been in the >> original spec, but it’s not. It doesn’t matter whether the client was >> registered dynamically or statically, it just matters that the AS knows >> what to expect from a given c

Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

Good catch Justin, thank you. I got the filed names switched around for some reason. On Sat, Nov 12, 2016 at 9:39 PM, Justin Richer wrote: > > > Nit on that section, the field name for the client metadata in RFC7591 is > token_endpoint_auth_method, the _supported version is from the > correspondi

Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

state this in the draft? > > best regards, > Torsten. > > Am 11.10.2016 um 05:59 schrieb John Bradley: > > At the request of the OpenID Foundation Financial Services API Working > group, Brian Campbell and I have documented > mutual TLS client authentication. This is some

Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

view that would be a workaround. > I would prefer that x5u, x5c and/or x5t was directly available in the > client registration request not via jwks. This would be a cleaner solution. > > Best Regards > Samuel > > On Fri, 11 Nov 2016 at 19:13, Brian Campbell > wrote: > &g

Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

egistration > specification (https://tools.ietf.org/html/rfc7591) with the certificate > parameter to actually do the registration or is that another document? > > >> I do think that more examples and guidance are warranted, though, to help >> AS developers. >> >> -- Justin

Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

ate Chain) parameter. > I do think that more examples and guidance are warranted, though, to help > AS developers. > Noted. > -- Justin > > On 11/2/2016 5:03 PM, Brian Campbell wrote: > > > On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman wrote: > >> >&g

Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman wrote: > > I agree it is written so that the connection to the certificate is > implicitly required but I think it would be better if it was explicit > written since the lack of a connection would result in a potential security > hole. > That's fai

Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

ou could stick the client_id (let me know if I'm >> wrong). If the AS is in doubt it will respond with invalid_client. I'm >> starting to think this can work quite well. No extra meta param will be >> needed (of which we have enough already). >> >> On 22/1

Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

there aren't that > many places where you could stick the client_id (let me know if I'm > wrong). If the AS is in doubt it will respond with invalid_client. I'm > starting to think this can work quite well. No extra meta param will be > needed (of which we have eno

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

item of the Web Authorization Protocol of the IETF. Title : OAuth 2.0 Token Exchange Authors : Michael B. Jones Anthony Nadalin Brian Campbell John Bradley Chuck M

Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

t; > Cheers, > > Vladimir > > On 10/10/16 23:59, John Bradley wrote: > > At the request of the OpenID Foundation Financial Services API Working group, > Brian Campbell and I have documented > mutual TLS client authentication. This is something that lots of people do

Re: [OAUTH-WG] Future of PoP Work

In my opinion, at this time, the OAuth WG should not proceed with the symmetric implementation of PoP and should not continue work on HTTP signing. On Wed, Oct 19, 2016 at 12:45 PM, Hannes Tschofenig < hannes.tschofe...@gmx.net> wrote: > Hi all, > > two questions surfaced at the last IETF meeting

Re: [OAUTH-WG] Shepherd Writeup for OAuth 2.0 for Native Apps

I believe there are a few small WGLC comments outstanding too. On Mon, Oct 10, 2016 at 4:30 AM, Hannes Tschofenig < hannes.tschofe...@gmx.net> wrote: > Hi all, > > Here is the shepherd writeup for the native apps document: > https://github.com/hannestschofenig/tschofenig-ids/blob/master/shepherd-

Re: [OAUTH-WG] Following up on token exchange use case

e to, of course, get some level of consensus around this. I'd like to publish a -06 draft soon and move things forward. I've got a few other smallish changes queued up but this has been sitting for 3+ weeks. So I'm looking to get to a resolution. On Fri, Sep 9, 2016 at 2:14 PM, Bri

[OAUTH-WG] explicit/implicit signaling to reveal TB ID

Sending this to both the Tokbind and OAuth lists. There is text now in HTTPSTB that says that a TB ID must only be conveyed to a different server, if the associated server explicitly singles to do so. Specifically these two snippets, https://tools.ietf.org/html/draft-ietf-tokbind-https-06#section

Re: [OAUTH-WG] Following up on token exchange use case

t; *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Justin Richer > *Sent:* Saturday, August 27, 2016 3:26 PM > *To:* Brian Campbell > *Cc:* > *Subject:* Re: [OAUTH-WG] Following up on token exchange use case > > > > No objections. Simplification is better, and th

Re: [OAUTH-WG] Following up on token exchange use case

. On Mon, Aug 1, 2016 at 2:00 PM, Brian Campbell wrote: > During the meeting in Berlin Tony voiced concern about a use case he had > for token exchange. Honestly, it's still not entirely clear to me what that > use case is or what would need to change in support of it. I'

Re: [OAUTH-WG] Call for adoption: Token Binding for OAuth 2.0

> is a good starting point as we would want a more generic solution for PoP > tokens in general > > > > *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Brian > Campbell > *Sent:* Tuesday, August 16, 2016 11:45 AM > *To:* Hannes Tschofenig > *Cc:* oauth@ie

Re: [OAUTH-WG] Call for adoption: Token Binding for OAuth 2.0

Just a friendly reminder that the 'deadline' for this call for adoption is tomorrow. According to the minutes from Berlin , 13 people were in favor of adopting OAuth 2.0 Token Binding and 0 were against. On Wed, Aug 3, 2016 at 1:45 AM,

Re: [OAUTH-WG] JWS JWT Access Tokens and resource audiences

Yeah, the client typically isn't the/an audience of an access token. The AT is opaque to the client and the client never processes or validates it. So aud would have the resource(s) and something else could carry the client id. FWIW, token exchange is looking to define and register "cid" as a JWT

Re: [OAUTH-WG] Call for adoption: Token Binding for OAuth 2.0

I accept these documents as a starting point of the Token binding work in OAuth. With emphases on "starting point" because even the initial discussions about the work in Berlin uncovered changes that'll be necessary or desirable. On Wed, Aug 3, 2016 at 1:45 AM, Hannes Tschofenig wrote: > Hi all

[OAUTH-WG] Following up on token exchange use case

During the meeting in Berlin Tony voiced concern about a use case he had for token exchange. Honestly, it's still not entirely clear to me what that use case is or what would need to change in support of it. I'd like to better understand the use case and see if it's something that can reasonably be

Re: [OAUTH-WG] OAuth Security -- Next Steps

Agree. The BCP would be larger in scope than just mix-up. And given that approach, I don't know if it makes sense to have a document specific to mix-up. On Mon, Jul 25, 2016 at 11:43 AM, Anthony Nadalin wrote: > Sounds about right, but I would imagine that the BCP would cover any issue > that ar

Re: [OAUTH-WG] Working Group Last Call on "OAuth 2.0 for Native Apps"

I likewise believe there is a lot of value in this work and support the document moving forward. I reviewed -03 and have just a couple nits: Loopback URI Redirection in section 3 (which the author is already aware of becaus

Re: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even overHTTPS

Yeah, in a Connect "code" only flow, the nonce is optional but if the client/RP sends and checks it, that should mitigate this. On Wed, Jul 27, 2016 at 1:19 AM, nov matake wrote: > In Connect, if RP verifies nonce value in ID Token issued from Token > Endpoint, code cut & paste attack can be mit

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

ndependentid.com > phil.h...@oracle.com > > > > > > On Jul 15, 2016, at 2:13 PM, Sam Whited wrote: > > Hi all, > > Longtime reader / implementer, first time poster. I wanted to comment > specifically on the question of the title: > > On Fri, Jul 15, 2016

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

Thank you, James, for the review and feedback. I apologize for the slow reply - on top of being a busy week this was a difficult one to respond to. It's disappointing to hear that it came off as conceited. That certainly wasn't the intent (though I suppose it rarely is). While I think there's ple

Re: [OAUTH-WG] Device flow clarifications

On Sat, Jul 9, 2016 at 12:28 PM, William Denniss wrote: > > On Fri, Jul 8, 2016 at 6:56 PM, Brian Campbell > wrote: > >> I hate to be pedantic but... well, here goes. >> > > Thanks for your review, it's important to get this right :-) > Well, I haven&#x

Re: [OAUTH-WG] Device flow clarifications

I hate to be pedantic but... well, here goes. Grant types other than those defined in RFC 6749 are supposed to be URIs (see section 4.5 on Extension Grants ). There's no registry for grant_type values so name collisions are avoided via the use of

Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tbpkce-00.txt

:s/Charis/Chairs/ On Fri, Jul 8, 2016 at 11:11 AM, Brian Campbell wrote: > This extremely short draft is an initial take at utilizing Token Binding > for PKCE. > > Charis, I'd like to request a small chunk of time in Berlin to present > this as part of the wider con

[OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-tbpkce-00.txt

ssage -- From: Date: Fri, Jul 8, 2016 at 10:25 AM Subject: New Version Notification for draft-campbell-oauth-tbpkce-00.txt To: <...> A new version of I-D, draft-campbell-oauth-tbpkce-00.txt has been successfully submitted by Brian Campbell and posted to the IETF repository. Name: dra

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

: OAuth 2.0 Token Exchange: An STS for the REST of Us Authors : Michael B. Jones Anthony Nadalin Brian Campbell John Bradley Chuck Mortimore Filename

[OAUTH-WG] RT treatment in Token Exchange

I gave a short presentation about OAuth 2.0 Token Exchange at a recent identity conference, which seemed well received and a lot of folks expressed their support for it and a desire to see support for i

Re: [OAUTH-WG] define a client_id JWT claim (in Token Exchange)?

im name rather than trying to match the > parameter name. > > > > John B. > >> On Jun 20, 2016, at 6:22 PM, Justin Richer wrote: > >> > >> +1 for “cid”, consistent with other JWT claims. > >> > >> — Justin > >> > >>> O

Re: [OAUTH-WG] define a client_id JWT claim (in Token Exchange)?

ch the > parameter name. > > > > John B. > >> On Jun 20, 2016, at 6:22 PM, Justin Richer wrote: > >> > >> +1 for “cid”, consistent with other JWT claims. > >> > >> — Justin > >> > >>> On Jun 20, 2016, at 5:21 PM, Brian Ca

[OAUTH-WG] define a client_id JWT claim (in Token Exchange)?

There is a somewhat poorly worded open issue in Token Exchange about being able to represent the client in the token. There is currently no standard claim for the client in JWT while Token Introspection defines a "client_id" parameter. It's maybe not the ideal place for it but Token Exchange could

Re: [OAUTH-WG] nit RFC 7662 Errata?

Some good irony in that message as I made a very similar mistake. The "IANA Considerations RFC 7591 / Token Introspection" link/text should say "IANA Considerations RFC 7591 / Client Registration <https://tools.ietf.org/html/rfc7591#section-4.1>". Sigh. On Mon, Jun

[OAUTH-WG] nit RFC 7662 Errata?

Because of my earlier message about act and may_act also being registered for Introspection Endpoint responses I was looking at the IANA Considerations of RFC 7662 and it seems like some text in the 2nd paragraph of Sec 3.1

[OAUTH-WG] another open issue in Token Exchange: short names for some common token type identifiers

Another open issue in Token Exchange is the question of should there be a way to use short names for some common token type identifiers? URIs are necessary in the general case for extensibility and vendor/deployment specific types. But short names like access_token and jwt are aesthetically appeal

[OAUTH-WG] Token Exchange's act and may_act claims also registered for Introspection Endpoint responses?

The question of if the act and may_act claims defined in Token Exchange should also be registered/defined for Introspection Endpoint responses was raised on this list a while back. Not much was said about it at the time but I did put an issue in github to keep track of it. I'd like to close out tha

[OAUTH-WG] closing an open issue about supplementary info in the Token Exchange request

A good while back in an off list conversation about Token Exchange, Chuck Mortimore mentioned that they "had a use-case for custom claims in where they essentially wanted to carry along metadata about a client or device for association to objects in our cloud." As a result of that conversation I ad

Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (4697)

Also agree On May 20, 2016 9:08 AM, "John Bradley" wrote: > Agreed this should be REJECTED. > > > On May 19, 2016, at 9:22 PM, Manger, James < > james.h.man...@team.telstra.com> wrote: > > > > I suggest this errata be REJECTED as token types are case-insensitive. > > > > Each field in RFC6749 tha

Re: [OAUTH-WG] Comments about PKCE / RFC7636

I believe that you're correct that the two cases you mention are not directly covered by PKCE. Some kind of user interaction should be required at the AS for public clients to prevent undetectable authz requests (I think maybe Android even enforces it). https://tools.ietf.org/html/draft-ietf-oauth

Re: [OAUTH-WG] Mix-Up and CnP/ Code injection

Sorry to chime in late but I wanted to say that I strongly agree with Torsten's characterization of things. On Sat, Apr 30, 2016 at 11:57 AM, Torsten Lodderstedt < tors...@lodderstedt.net> wrote: > Hi Nat, > > sure, one could also authenticate and cryptographically protect the > redirect response

Re: [OAUTH-WG] Building on the protocol in the draft “OAuth 2.0 Token Exchange: An STS for the REST of Us” to include Authentication Tokens

thank you for your input. Per my prior response to John > Bradley, our use case has the Identity Provider being provided by a > different organization than the organization providing the Authorization > Service. > > Thanks, > Andy > > From: Brian Campbell > Date: Tu

Re: [OAUTH-WG] Building on the protocol in the draft “OAuth 2.0 Token Exchange: An STS for the REST of Us” to include Authentication Tokens

The Token Exchange draft does put the Authorization Server (AS) in the role of STS because it's an extension of OAuth. But that shouldn't be viewed as limiting. An AS is often deployed as one part of an Identity Provider. OpenID Connect, as John mentioned, is one standard that combines the roles. A

Re: [OAUTH-WG] Meeting Minutes

Yeah, as I recall, there was at least some support around the idea of an "enhanced OAuth security" document. On Sun, Apr 17, 2016 at 2:46 AM, Torsten Lodderstedt < tors...@lodderstedt.net> wrote: > Hi all, > > the security discussion started with mix up and cut and paste, but we had > a much broa

Re: [OAUTH-WG] Question on draft-ietf-oauth-token-exchange-04

I will work to try and clarify in the next draft but would happily listen to suggestions. On Mon, Apr 11, 2016 at 2:26 PM, Brian Campbell wrote: > The intent is that urn:ietf:params:oauth:token-type:access_token be an > indicator that the token is a typical OAuth access token issued by

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

ead goes on shows how unstable and not fully thought out this draft is > to go through WG adoption. > > > > *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Brian > Campbell > *Sent:* Monday, April 11, 2016 12:30 PM > *To:* Nat Sakimura > *Cc:* > *Subject:* R

Re: [OAUTH-WG] Question on draft-ietf-oauth-token-exchange-04

The intent is that urn:ietf:params:oauth:token-type:access_token be an indicator that the token is a typical OAuth access token issued by the AS in question, opaque to the client, and usable the same manner as any other access token obtained from that AS (it could well be a JWT but the client isn't

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