[OAUTH-WG] I-D Action: draft-ietf-oauth-pop-key-distribution-05.txt

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 Proof-of-Possession: Authorization Server to Client Key Distribution Authors : John Bra

[OAUTH-WG] draft-ietf-oauth-pop-key-distribution-05

I just submitted -05 of the draft. The updates are limited to author info updates and minor editorial nits. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender

[OAUTH-WG] OAuth WG Virtual meeting this week

All, The meeting time for this week has not changed, which means it will be one hour later for people that moved to Daylight Savings Time (1:00pm Eastern Time). Regards, Rifaat ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo

[OAUTH-WG] I-D Action: draft-ietf-oauth-pop-key-distribution-06.txt

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 Proof-of-Possession: Authorization Server to Client Key Distribution Authors : John Bra

[OAUTH-WG] draft-ietf-oauth-pop-key-distribution-06

Well. I made a mistake with version -05. Now there is a version -06 Ciao Hannes From: OAuth On Behalf Of Hannes Tschofenig Sent: Montag, 11. März 2019 13:52 To: oauth Subject: [OAUTH-WG] draft-ietf-oauth-pop-key-distribution-05 I just submitted -05 of the draft. The updates are limited to

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

Yes, that's how I implemented it as well. I return 'invalid_request' when the client_id is missing entirely. Do you have any thoughts how this specification should work in combination with other specs, such as OIDC? For example, the OIDC Authentication Request specifies several additional paramete

[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 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, I believe

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

If we're about to add client authentication for the device_authorization_endpoint, i'd say we should also register for device_authorization_endpoint_auth_method, device_authorization_endpoint_auth_signing_alg client metadata. Maybe define the default value to be "none" / not provided to be in line

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

Strike that, it should maybe just use the registered auth method for the token endpoint? If there's auth we should also make it clear that client_id should not be omitted from the request body and it must be the same as the one provided with client authentication. S pozdravem, *Filip Skokan* On

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

On Mon, Mar 11, 2019 at 10:22 AM Filip Skokan wrote: > Strike that, it should maybe just use the registered auth method for the > token endpoint? > Yeah, that's what I'd think would be the way to go. > > If there's auth we should also make it clear that client_id should not be > omitted from t

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

+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 at 10:22 AM Filip Skokan > wrote: Strike that, it should maybe just use the registered auth method for the token endpoint?

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

+1 to using same authentication requirements as for token endpoint. Phil > On Mar 11, 2019, at 10:27 AM, George Fletcher > 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 at 1

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

Hi Emond, the way i approached implementation of device flow into an OIDC server was to allow all already registered and handled parameters excluding the ones [1] that really don't make sense for the flow at the device authorization endpoint. What can be validated at the device authorization endp

Re: [OAUTH-WG] OAuth Digest, Vol 125, Issue 10

regards, > > >> Emond Papegaaij > > >> Topicus KeyHub > > >> > > >> > > >> ___ > > >> OAuth mailing list > > >> OAuth@ietf.org > > >> https://www.ietf.org/m

[OAUTH-WG] Nested JWT draft

Hi, I have just submitted the following short draft with some *initial thoughts *on extending the Nested JWT concept defined in the RFC7519, to allow the enclosing JWT to have its own Claims Set. https://www.ietf.org/id/draft-yusef-oauth-nested-jwt-00.txt I would appreciate any reviews and commen

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

And thank you, William, for being responsive about it. On Mon, Mar 11, 2019 at 1:18 PM William Denniss wrote: > Thank you Brian for raising this. > > Yes, the expectation I believe is to follow the same approach as the token > endpoint. As the spec is primarily for public clients, that's what w

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 about it. >> >> >> On Mon,

[OAUTH-WG] Typo in Device flow 5.2

Hi all, It seems the word 'no' is missing in section 5.2 of the OAuth 2.0 Device flow: As the device code is not displayed to the user and thus there are *NO* usability considerations on the length, a very high entropy code SHOULD be used. Best regards, Emond Papegaaij Topicus KeyHub __

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

Hi Filip, Yes, this was exactly what I was thinking about. Good to know I'm working in the right direction. I must say that the spec reads really well and is fairly straightforward to implement. Best regards, Emond Papegaaij Topicus KeyHub On Mon, Mar 11, 2019 at 6:29 PM Filip Skokan wrote: > >

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

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 Device Authorization Grant Authors : William Denniss John Brad

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

Hi all, during today's office hours call I pointed out that oauth-mtls-13's abstract only mentions access token, although the spec does provide (some) guidance on refresh token binding as well. Although in the end implementers would do the right thing, given that they have to read the spec in its

[OAUTH-WG] OAuth Device Flow spec renamed to “OAuth 2.0 Device Authorization Grant”

I made a blog post about the renaming of the device spec and last-minute clarifications applied at http://self-issued.info/?p=1959 and @selfissued. Thanks again to William for doing the heavy lifting! Hopefully this is the version that gets sent to the RFC Edito

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-key-distribution-06.txt

Syntax glitches in draft-ietf-oauth-pop-key-distribution-06: 1. "exp" and "nbf" values should be numbers, not strings, so must not have quotes [Section 4.2.2. "Client-to-AS Response"] 2. h'11' and b64'...' appear in the JSON examples, but should be "..." strings [Section 4.2.2. "Client-to-AS Re