----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: keycloak-dev(a)lists.jboss.org
Sent: Thursday, January 15, 2015 5:07:22 PM
Subject: Re: [keycloak-dev] KEYCLOAK-884 - UserInfo Endpoint
On 1/15/2015 12:40 PM, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Pedro Igor Silva" <psilva(a)redhat.com>
>> To: "keycloak dev" <keycloak-dev(a)lists.jboss.org>
>> Sent: Thursday, January 15, 2015 2:46:11 PM
>> Subject: KEYCLOAK-884 - UserInfo Endpoint
>>
>> Bill,
>>
>> Is the work you are doing for claims considering the respective
>> sections
>> in OpenID Connect specification ? To be more specific,
>>
http://openid.net/specs/openid-connect-core-1_0.html#Claims.
>>
>> Depending on what you are doing, I think I would need to wait you
>> finish
>> in order to full support what is expected from the UserInfo endpoint.
>> Meanwhile, I'm already doing everything that is necessary to get the
>> endpoint up and running with a basic interoperability based on the
>> default scope values used to request claims (profile, email, address,
>> phone).
>>
>> Btw, are you planning to configure any type of configuration in order
>> to
>> setup the privacy of certain claims ?
>
> Forget about it. Just noticed you already have support for that.
>
Nothing beyond a few claims though. Can't enter in address, phone, etc...
I've submitted a PR for this issue. There are some changes to IDToken type that would
like to share and discuss.
Today, user claims are strongly tied with the IDToken type. They are there as properties
of the type itself. From a token perspective, that is how they are represented but from an
internal perspective I think we can improve it a little bit by introducing a specific type
for user claims.
IMO, a best design is to extract those specific claims from IDToken type and get them into
a specific UserClaimSet, which also helps to avoid code duplication when claims are needed
in different places. Just like we need it in UserInfo.
That allow us to better represent/manage user claims internally and keep things more in
sync with the specs, without break anything from a token representation or functionality
perspective.
Any thoughts ?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev