+1, I've found the very same in OAuth deployments that I was involved
in; the hard part is to give names and descriptions to these concepts so
that they cover all use cases and can be applied unambiguously
Hans.
On 3/14/16 10:44 PM, Justin Richer wrote:
I agree that this is valuable, and not
Yes Brian and I discussed the reasons for separating
audience/resource/destination from scope yesterday, and how that might impact
token exchange and the need to align.
I think this is a core problem that needs to be addressed.
The mixup at the resource is posable because scope is too overlo
I agree that this is valuable, and not just for PoP. In all honesty, it’s not
even really required for PoP to function in many cases — it’s just an
optimization for one particular kind of key distribution mechanism in that case.
In the years of deployment experience with OAuth 2, I think we’ve r
I would really like to see a comprehensive solution not this piece work, so we
know what we are solving and what we are not.
-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hans Zandbelt
Sent: Monday, March 14, 2016 3:26 PM
To: Phil Hunt (IDM) ; John Bradley
C
Yes I will work on another proposal for allowing clients to specify what
resource they want a token for and providing the meta-data to the client about
the resources that a token is valid for.
We have part of it in the POP key distribution spec and talked about separating
it, as it is used more
On 3/14/16 10:17 PM, Phil Hunt (IDM) wrote:
On Mar 14, 2016, at 14:13, John Bradley mailto:ve7...@ve7jtb.com>> wrote:
Any client that has the resource and issuer hard coded probably
doesn’t need discovery.
We agree
Yet any client that has hard coded a resource and 2 issuers doesn't need
dis
Inline
Phil
> On Mar 14, 2016, at 14:13, John Bradley wrote:
>
> We had two mandates. One was to provide a spec for AS metadata. The other
> was to mitigate the client mixup attack. The request was to do the latter
> without requiring the former for clients that don’t otherwise need disco
We had two mandates. One was to provide a spec for AS metadata. The other
was to mitigate the client mixup attack. The request was to do the latter
without requiring the former for clients that don’t otherwise need discovery.
Returning the issuer and client_id from the authorization endpoint
We don’t include the scopes or identity information in the token itself, so as
to prevent it from leaking to parties that shouldn’t need it.
The main benefit of introspection is liveness, but it also lets you reference
data tied to the token that you don’t want to ship in the token itself.
At
Sorry your first email didn’t mention introspection.
I answered assuming a JWT.
A JWE can have the issuer in the envelope, so the recipient just needs to
base64url decode the envelope to see who it issuer was and from that determine
where to introspect it.
However if you are introspecting the
Thanks to Mike and John for their feedback. I’ll take each in turn:
Mike,
Regarding your suggested amendments
Item 1: Returning the config URL would create two problems. One,it makes bound
discovery a two-step process - that adds complexity. It seems far simpler to
mandate TLS (which I think
This was the original requirement:
" multiple authorization servers that can issue access tokens for one
resource server, when the resource server receives an access token from
a client application, as the first step, the resource server has to
determine which authorization server to use for a
Dear Hannes Tschofenig,
The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request.
oauth Session 1 (2:00:00)
Wednesday, Morning Session I 1000-1230
Room Name: Buen Ayre B size: 125
-
For what it's worth, we deployed such a system in 2011 using signed
JWTs, symmetric keys and supporting key rotation via the kid JWT header
field. The body of the JWT includes 'iss', 'exp', 'uid' (for the user),
'access_token' (AS specific opaque blob), and 'validation_url' (where to
validate t
Mike, there is no need to rush standardizing the metadata since there are still
obvious issues with discovery or what one thinks discovery should be and should
not be. This is also not the OpenID Foundation, this group should not be
constrained by what OpenID has done but we should be informed.
15 matches
Mail list logo
