My understanding is that it is considered a best practice to rollover a
refresh token on each use - that is when a refresh token is used, both a
new access token and a new refresh token are issued, and the old refresh
token is revoked.
The primary reason I have seen cited for this is it would allo
As I read back through this one I’m not getting why you need a new refresh
token. What am I missing? -T
On Mon, Nov 26, 2012 at 6:27 PM, Brian Eaton wrote:
> On Fri, Nov 23, 2012 at 4:43 AM, Bob Gregory wrote:
>
>> We've had OAuth2 running successfully for a while now, but we're finding
>> th
On Fri, Nov 23, 2012 at 4:43 AM, Bob Gregory wrote:
> We've had OAuth2 running successfully for a while now, but we're finding
> that mobile applications have frequent problems with the refresh flow where
> a refresh request is made, but the network connection fails before the new
> AT/RT pair is
--- As Justin pointed out please indicate your availability for the conference
calls.
--
• From: Hannes Tschofenig
• To: "oauth at ietf.org WG"
• Date: Wed, 21 Nov 2012 23:05:21 +0200
Hi all,
Based on the discussions at the OAuth WG meeting at IETF#85 we are tryi
Hi Sergey,
as Phil said it would be helpful for us to receive reviews of this document:
http://tools.ietf.org/html/draft-tschofenig-oauth-security-00
The document lists requirements and threats.
Ciao
Hannes
On Nov 26, 2012, at 8:28 PM, Phil Hunt wrote:
> If we want to get this done we have t
The idea is that registration is how you get/set the credential to use at the
other endpoints.
Bootstrapping and updating that with a bearer token is not unreasonable.
The larger problem is that the password credential at the token endpoint is a
bit of an anachronism.
In my opinion we should be
I don't know that we need user_id in the JWT spec it may be enough to have it
as a OIDC extension if it is not globally useful.
I agree that the definition of prn should be more specific.
On 2012-11-26, at 3:56 PM, Torsten Lodderstedt wrote:
> Hi John,
>
> does it make sense to change the spec
Hi Justin,
Am 26.11.2012 15:51, schrieb Justin Richer:
Hi Torsten, thanks for the comments.
Whats the advantage of having two secrets for the same client_id,
namely request_access_token and client_secret? Why not always issuing
a secret and use it for authentication on this endpoint (in the s
Hi John,
does it make sense to change the spec as follows:
- specify the prn claim as being globally unqiue
- add user_id as scoped by iss claim
What do you think?
regards,
Torsten.
Am 26.11.2012 19:51, schrieb John Bradley:
A user_id is scoped to a iss.
There is some notion that a prn is g
A user_id is scoped to a iss.
There is some notion that a prn is globally unique, though the JWT spec is not
clear on that. I think people are thinking of it like a UPN in LDAP/AD.
John B.
On 2012-11-26, at 3:46 PM, Torsten Lodderstedt wrote:
> Hi John
>
> thanks for the explanatian. Just t
I agree with Bill's statement and have stated so on several occasions. I
think it's clear that we've got several use cases that are interested in
different things, and I think that there's very little chance that we're
going to have one super amazing specification that can cover all of
them. I
Hi John
thanks for the explanatian. Just to make sure I got you right. A prn can be a
user_id. A prn is bound to the scope of an iss.
Regards,
Torsten.
John Bradley schrieb:
>JWT is more generic than OIDC.
>
>prn and user_id as used by OIDC are similar. user_id is already in
>wide use wit
I agree that HOK may be independent of MAC and should be a separate issue, as
MAC does not solve my proof of possession for a HOK solution
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
William Mills
Sent: Monday, November 26, 2012 10:42 AM
To: Phil Hunt; Sergey Beryoz
I object to tying MAC to HOK, I see them as independent and I frankly don't
understand why folks insist that MAC can not proceed without a broader HOK
spec.
-bill
From: Phil Hunt
To: Sergey Beryozkin
Cc: ""
Sent: Monday, November 26, 2012 10:28 AM
Subje
If we want to get this done we have to get agreements on the requirements for
HOK. Several meetings ago (quebec) the group indicated that mac wasn't
appropriate to anyone's needs.
Some would argue that OAuth1 users arguably have less security than the simpler
bearer token /tls model in OAuth2.
Hi
What needs to be done to complete the MAC token spec ? Without having it
signed off it will be difficult to get people working with OAuth 1.0
convinced to move to 2.0.
I'm seeing another user request for getting OAuth 1.0 support extended
further because the user expects it is more secure,
I have reviewed the document, and it looks ready to go.
-- Justin
On 11/24/2012 01:13 PM, Hannes Tschofenig wrote:
Hi all,
this is a working group last call for draft-ietf-oauth-revocation-03 on "Token
Revocation". The draft is available here:
http://tools.ietf.org/html/draft-ietf-oauth-rev
Hi Torsten, thanks for the comments.
Whats the advantage of having two secrets for the same client_id,
namely request_access_token and client_secret? Why not always issuing
a secret and use it for authentication on this endpoint (in the same
way as at the token endpoint)?
Two things are at pla
JWT is more generic than OIDC.
prn and user_id as used by OIDC are similar. user_id is already in wide use
with Facebook's signed request.
We were hoping that Facebook would be more likely to migrate from signed
request to JWT if the parameter names stayed the same for developers.
In the ge
Torsten,
Originally in OIC we defined using the client secret to access the registration
endpoint.
We received a lot of feedback that having it bearer protected for the first
access and password protected for subsequent access was confusing.
There are also the cases where there is no need for
Draft -08 of the Assertion Framework for OAuth 2.0 has been published with
only minor changes to clean up the IANA Considerations section and to
update references from draft-ietf-oauth-urn-sub-ns to RFC 6755.
-- Forwarded message --
From:
Date: Mon, Nov 26, 2012 at 7:01 AM
Subject
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 : Assertion Framework for OAuth 2.0
Author(s) : Brian Campbell
C
Hi Bob,
On 26/11/12 10:47, Bob Gregory wrote:
Hi Sergey,
We are less concerned about failure during the initial authorization,
since an end-user might reasonably expect to be asked to sign in again
if a failure occurs.
Indeed
What's awkward here is that the user has been
successfully using t
On 23/11/12 12:43, Bob Gregory wrote:
We've had OAuth2 running successfully for a while now, but we're finding
that mobile applications have frequent problems with the refresh flow
where a refresh request is made, but the network connection fails before
the new AT/RT pair is received, leading to
Hi Torsten,
thanks for the draft update. It looks good to me.
I only have a minor wording suggestion for Section 3.
Instead of
"
Depending on the authorization server's token design, revocation of
access tokens might be a costly process. For example, revocation of
self-contained acc
25 matches
Mail list logo
