Using structured access tokens to do delegation or convey other claims to the
RS can and should be separate from the assertions delivered to the client.
The tokens will have different audiences and if using Proof of Possession
different presenter key material.
Using one token for both things ma
Looking at the latest draft
http://tools.ietf.org/html/draft-hunt-oauth-v2-user-a4c-03 it is better.
As far as I can see he deltas from Connect Basic profile are:
1 A new response_type "code_id_token" (I think the similarity to the "code
id_token" response_type may cause some confusion but tha
A core issue for me is that authentication and access are two separate
functions. Some clients want authentication context only. Some want access
only, some want both.
If you combine both complexity ensues (such as loss of opaqueness, needing
introspection, etc etc).
Phil
phil.h...@yahoo.c
If you need user info based on an access token the introspection endpoint is
the right way to go. Even so, there's issues with using an access token as an
authenticator and this is a major reason why OpenID is the right way to go for
authn.
On Thursday, June 5, 2014 12:42 PM, Anthony Nadalin
Delegation
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Thursday, June 5, 2014 12:45 PM
To: Anthony Nadalin
Cc: Bill Mills; Phil Hunt; oauth@ietf.org
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
Examples?
Am 05.06.2014 um 21:42 schrieb Anthony Nadal
No, it's great exactly *because* you can represent things in the access token
that make sense for your app/domain and it stays opaque to the parties who
shouldn't care: the clients. Access tokens aren't opaque to the AS (or PR),
because of OAuth's flexibility of token formats you can use what wo
Examples?
> Am 05.06.2014 um 21:42 schrieb Anthony Nadalin :
>
> It’s great but some ways but also very limiting if you are counting on
> certain requirements to be represented in the access token
>
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt
> Sent: Thursday
It’s great but some ways but also very limiting if you are counting on certain
requirements to be represented in the access token
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt
Sent: Thursday, June 5, 2014 12:40 PM
To: Bill Mills
Cc: Phil Hunt; oauth@ietf.org
Subject
+1
the access token is opaque to the client. That's great! Let's keep it that way.
> Am 05.06.2014 um 21:20 schrieb Bill Mills :
>
> Can't agree more with the peril of overloading auth information into an
> access token.
>
>
> On Thursday, June 5, 2014 11:05 AM, Mike Jones
> wrote:
>
>
>
BTW, I just spotted a problem with the example response at the bottom of
section 4.1, the HTTP status code should be 201 Created:
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-17#section-4.1
Vladimir
___
OAuth mailing list
OAuth@ietf.org
https:/
Can't agree more with the peril of overloading auth information into an access
token.
On Thursday, June 5, 2014 11:05 AM, Mike Jones
wrote:
Hannes, the Access Token and ID Token do quite different things and have
different structures and properties. The Access Token is an opaque value th
The answer to your question about the Initial Access Token and Software
Statement is highly parallel to the answer to your question in the other thread
about the Access Token and ID Token. :-) The Initial Access Token and the
Software Statement do quite different things and have different struc
Hannes, the Access Token and ID Token do quite different things and have
different structures and properties. The Access Token is an opaque value that
grants access to resources. An ID Token is a non-opaque JWT security token
that makes claims about the authentication that occurred. You can h
Hannes,
I’ll clarify the software statement and let Mike/Justin respond for the rest.
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On Jun 5, 2014, at 12:42 AM, Hannes Tschofenig
wrote:
> Hi Justin, Hi Mike,
>
> thanks for updating the document so quickly.
>
> I have re-
You are correct. Just adding to access token would make a lot of devs happy and
that certainly should be discussed.
Two requirements issues:
1. A key use case is passing auth ctx only. An access token means asking for
consent to access something. This causes many sites to loose new users. Auth
Hi Phil,
thanks for producing this document write-up. I have a somewhat basic
question regarding the document.
The id token contains the following mandatory information:
- sis: issuer
- sub: subject
- aud: audience
- iat: issued at
- exp: expiry
- auth_time: time when the end user was authe
Hi Justin, Hi Mike,
thanks for updating the document so quickly.
I have re-read the new version and I have a few minor comments.
You write: "The following client metadata fields are defined by this
specification. All client metadata fields are OPTIONAL."
I guess you mean "Optional to implement
17 matches
Mail list logo
