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

[Brian Campbell]

Thank you

On Fri, Aug 28, 2015 at 7:04 PM, Mike Jones 
wrote:

> 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:* Tuesday, August 11, 2015 4:05 PM
> *To:* Mike Jones
> *Cc:* Brian Campbell; oauth
> *Subject:* Re: [OAUTH-WG] proof-of-possession-02 unencrypted oct JWK in
> encrypted JWT okay?
>
>
>
> OK
>
> On Aug 11, 2015, at 12:57 AM, Mike Jones 
> wrote:
>
>
>
> As discussed in the thread “[OAUTH-WG] JWT PoP Key Semantics WGLC followup
> 2 (was Re: proof-of-possession-02 unencrypted oct JWK in encrypted JWT
> okay?)”, I will update the draft to say that the symmetric key can be
> carried in the “jwk” element in an unencrypted form if the JWT is itself
> encrypted.  This will happen in -04.
>
>
>
> -- Mike
>
>
>
> *From:* OAuth [mailto:oauth-boun...@ietf.org ] *On
> Behalf Of *Brian Campbell
> *Sent:* Sunday, March 22, 2015 11:41 PM
> *To:* oauth
> *Subject:* [OAUTH-WG] proof-of-possession-02 unencrypted oct JWK in
> encrypted JWT okay?
>
>
>
> When the JWT is itself encrypted as a JWE, would it not be reasonable to
> have a symmetric key be represented in the cnf claim with the jwk member as
> an unencrypted JSON Web Key?
>
> Is such a possibility left as an exercise to the reader? Or should it be
> more explicitly allowed or disallowed?
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

You’re welcome.  Thanks, as always, for the useful feedback that improved the 
specification.

From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Monday, August 31, 2015 1:47 PM
To: Mike Jones
Cc: oauth
Subject: Re: [OAUTH-WG] proof-of-possession-02 unencrypted oct JWK in encrypted 
JWT okay?

Thank you

On Fri, Aug 28, 2015 at 7:04 PM, Mike Jones 
> wrote:
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: Tuesday, August 11, 2015 4:05 PM
To: Mike Jones
Cc: Brian Campbell; oauth
Subject: Re: [OAUTH-WG] proof-of-possession-02 unencrypted oct JWK in encrypted 
JWT okay?

OK
On Aug 11, 2015, at 12:57 AM, Mike Jones 
> wrote:

As discussed in the thread “[OAUTH-WG] JWT PoP Key Semantics WGLC followup 2 
(was Re: proof-of-possession-02 unencrypted oct JWK in encrypted JWT okay?)”, I 
will update the draft to say that the symmetric key can be carried in the “jwk” 
element in an unencrypted form if the JWT is itself encrypted.  This will 
happen in -04.

-- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Sunday, March 22, 2015 11:41 PM
To: oauth
Subject: [OAUTH-WG] proof-of-possession-02 unencrypted oct JWK in encrypted JWT 
okay?

When the JWT is itself encrypted as a JWE, would it not be reasonable to have a 
symmetric key be represented in the cnf claim with the jwk member as an 
unencrypted JSON Web Key?
Is such a possibility left as an exercise to the reader? Or should it be more 
explicitly allowed or disallowed?

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Lifetime of refresh token

[Donghwan Kim]

@John, @William I'm of exactly the same opinion. When refreshing the token
on expiration of the access token, a new exchange of access token and
refresh token should be issued unless that refresh token expired due to
inactivity of 1 month or is invalidated by user through their some setting
pages. Then, new 1 month of expiration starts again, which is what I called
the persistent login.

@Bill Come to think of it, it makes sense. If user lose his/her phone or
something, he/she should invalidate the token issued to that device.
Waiting for one month doesn't help.

@Jim Your point is quite valid :) BTW, a self-descriptive access token that
only the server understand may be able to cover some of profiles. For
example, if the access token contains when the user is signed, banking
resource server can ask user to sign in again, insisting such operation
should be performed only within 10 minutes of signing in.

Thanks for all replies!

-- Donghwan

On Sat, Aug 29, 2015 at 6:38 AM, Jim Manico  wrote:

> 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 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, banking,
> enterprise, etc) as opposed to one recommendation.
>
> With respect,
> Jim Manico
>
> On 8/28/15 10:41 AM, 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 want for a inactivity timeout after which the user must
> authenticate again.   The user can always revoke the refresh token.
>
> Rolling the refresh token also has the advantage that if the token leaks
> or is stollen then you will detect the second use of the expired refresh
> token and invalidate both, so the user needs to loggin.
>
> In general I think rolling the refresh token is a good idea though it is
> not popular, I think it is more secure.
>
> John B.
>
>
>
> On Aug 28, 2015, at 11:21 AM, Donghwan Kim 
> wrote:
>
> 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 refresh token should have 1 month of expiration time by default. If it
> turns out that some access token expired, its refresh token should refresh
> the token. Then, so called persistent login can be implemented regardless
> of the form of authentication. Only if it fails for some reason e.g. token
> revocation or inactivity for 1 month, a user is logged out automatically
> and should log in again.
> * A refresh token should be able to be revoked somehow. With 5 minutes
> approach, it will invalidate only the refresh token (Yes the attacker can
> have 5 minutes at most), and with 1 hour approach, it will invalidate the
> refresh token as well as the corresponding access token.
>
> Thanks,
>
> -- Donghwan
>
> On Fri, Aug 28, 2015 at 5:43 PM, Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
>> 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:08:21 MESZ, schrieb John Bradley :
>>
>>>
>>> I think Nat’s diagram about the problems of doing pseudo authentication
>>> with OAuth is being taken out of context.
>>>
>>> The refresh token dosen’t expire, it is revoked by the user or system.
>>> In some cases refresh tokens are automatically revoked if the users session
>>> to the AS ends.  I think AOL typically revokes refresh tokens when sessions
>>> terminate.
>>>
>>> OpenID Connect provides a separate id_token with a independent lifetime
>>> from the refresh token.  A client may keep a refresh token for a much
>>> longer time than the user has a login session with the AS.
>>>
>>> Refresh tokens are typically used by confidential clients that are using
>>> a client secret in combination with the refresh token for getting a new
>>> access token.
>>>
>>> By design access tokens should be short lived as the AS is expected to
>>> have a way of revoking refresh tokens but not access tokens.
>>> A access token that dosen't expire , and can’t be revoked is not a good