In OpenID Connect, aggregated and distributed claims are ways for the
OpenID Provider to reference claims issued by other entities (e.g.
attribute provider or "Issuer" in the SSI sense). There is no
requirement from a spec perspective that the /userinfo endpoint be
co-located with the AS. It seems to me that whether a /userinfo endpoint
uses opaque or structured tokens is orthogonal to the need for access
token claim definition.
It may be useful reference the claims specifications in OpenID Connect
as a reference for user claim values in addition to the claims defined
in the JWT spec.
Thanks,
George
On 5/6/19 3:49 PM, Vladimir Dzhuvinov wrote:
On 06/05/2019 22:26, Vittorio Bertocci wrote:
I am not following, Vladimir. What do you mean? Can you make some examples
to clarify?
The userinfo is always colocated with the AS, hence I would expect most
vendors not to use JWT for the ATs issued for userinfo access
That's what I was curious about, if there are any deployments with the
UserInfo not being co-located.
OpenID Connect also has this exotic use case, called distributed claims:
https://openid.net/specs/openid-connect-core-1_0.html#DistributedExample
If co-location is the common case, then there's really no need to spec a
JWT claim for that.
Vladimir
On Mon, May 6, 2019 at 12:21 PM Vladimir Dzhuvinov <vladi...@connect2id.com>
wrote:
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-00#section-2.2.2
In OpenID Connect the access token is consumed by the UserInfo endpoint.
Were there any suggestions to also spec parameter(s) for the claims
names (with optional locales) for release at the UserInfo endpoint?
Vladimir
_______________________________________________
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
