Re: [OAUTH-WG] proof-of-possession-02 unencrypted oct JWK in encrypted JWT okay?

This was added at the end of Section 3.2 in -04. Thanks again for the practical feedback, Brian! -- Mike From: John Bradley [mailto:ve7...@ve7jtb.com] Sent: Tuesd

Re: [OAUTH-WG] Review Comments for draft-ietf-oauth-proof-of-possession-02

Thanks again for your detailed review, Nat. The remainder of the issues you raised are addressed in the -04 draft. Replies are inline prefixed by Mike> … From: Nat Sakimura [mailto:sakim...@gmail.com] Sent: Tuesday, August 18

[OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing remaining comments

Proof-of-Possession Key Semantics for JWTs draft -04 addresses the remaining working group comments received - both a few leftover WGLC comments and comments received during IETF 93 in Prague. The changes were: * Allowed the use of "jwk" for symmetric k

[OAUTH-WG] I-D Action: draft-ietf-oauth-proof-of-possession-04.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 Working Group of the IETF. Title : Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) Authors : Michael B. Jon

Re: [OAUTH-WG] Lifetime of refresh token

I stand corrected, the RFC does give specific time recommendations such as 10 minutes authorization code recommendation here https://tools.ietf.org/html/rfc6749#section-4.1.2 but I think my overall point is still valid. :) Aloha, Jim On 8/28/15 11:36 AM, Jim Manico wrote: Again, I would st

Re: [OAUTH-WG] Lifetime of refresh token

Again, I would state that this is all contextual to the application being built - which is why the RFC never gives specific times other than "short lived" or "long lived". I would suggest giving a series of recommendations relative to a few different risk profiles (low risk, social media, banki

Re: [OAUTH-WG] Lifetime of refresh token

This is all contextual to the application. In some situations I want to immediately force re-authentication for all transactions above X$ such as banking applications. In some situations I want a permanent refresh token, like for Twitter like social applications. etc...etc... - Jim Manico O

Re: [OAUTH-WG] Lifetime of refresh token

+1 for John's suggestion. Why force users to re-authenticate after an arbitrary 30-day window? On Fri, Aug 28, 2015 at 1:41 PM John Bradley wrote: > I would use a 5 min AT and roll the refresh token per > https://tools.ietf.org/html/rfc6749#page-47 with a 1 month expiry if that > is what you wa

Re: [OAUTH-WG] Lifetime of refresh token

I would use a 5 min AT and roll the refresh token per https://tools.ietf.org/html/rfc6749#page-47 with a 1 month expiry if that is what you want for a inactivity timeout after which the user must authenticate again. The user can always revoke the

Re: [OAUTH-WG] Lifetime of refresh token

One viable method for detecting “inactivity for one month” would be to have a one month expiration on the refresh token, but reset that counter every time the refresh token is used to get a new access token. You can do this by manipulating the expiration of the token object itself on your author

Re: [OAUTH-WG] Lifetime of refresh token

You don't need to put an expiration on the refresh token.  You get to see that refresh token every 5 minutes anyway.  If you ever want to force the client to re-auth just use policy on the AS.  Nothing will be broken with what you are doing though. On Friday, August 28, 2015 7:21 AM, Don

Re: [OAUTH-WG] Lifetime of refresh token

I'm sorry to introduce a common topic. As John has suggested, I'm going to design that * An access token should be short lived e.g. 5 minutes (not to hit the AS to verify the token or 1 hour (to hit the AS to verify the token). I'm inclined to 5 minutes for stateless architecture of RSs. * A refr

Re: [OAUTH-WG] Lifetime of refresh token

Refresh tokens are also used by public clients, e.g. native apps. OIDC allows to acquire a new id token from a refresh token as well. Note: this does not mean a fresh authentication but a refreshed id token containing the data of the original authentication transaction. Am 24. August 2015 17:0