Hi Pushpalanka,
As per the offline discussion, here in the request object we should support
to both user claims and the transaction claims. For the user claims IS
server should store consents with the claims and for the transaction claims
the extended solution should handle the consents. We discussed three below
options regarding persisting claim - consent mapping in server level.
1. Introduce a new table.
2. Change IDN_OPENID_USER_RPS table to persist claim - consent mapping.
3. In the registry file persist every single claim as a scope in such a way
:
Current situation: Scope1 : claim1, claim2,claim3
For the solution : claim1 : claim1
claim2 : claim2
As we are planning to do this via WUM update we thought of going with the
option 3 in order to avoid schema changes.
Further when providing consents ideally we need to provide consents one by
one for every single claim. But if the server gets multiple claims then
providing claims one by one will hard for the end user. So I think we
should provide the option for the user to select the way of providing
consents as the whole bunch together or one by one. Any way as the consent
page is customizable this wont be a big issue.
>From IS level :
1. We will implement request parameter
2. Will support consents for the user claims
3. Will provide extension points for signing and encryption the jwt
4. Will provide set of user claims and transaction claims separately using
the extension
5. Will catch the request_uri parameter from the server and pass it to the
extension point.
@Pushpalanka, please add if I have missed anything.
Thanks,
Hasanthi Dissanayake
Software Engineer | WSO2
E: hasan...@wso2.com
M :0718407133| http://wso2.com <http://wso2.com/>
On Thu, Oct 12, 2017 at 9:54 AM, Pushpalanka Jayawardhana <la...@wso2.com>
wrote:
> Hi Hasanthi,
>
> On Wed, Oct 11, 2017 at 11:10 PM, Hasanthi Purnima Dissanayake <
> hasan...@wso2.com> wrote:
>
>> Hi Pushpalanka,
>>
>> Since scope concept is no longer effective in this approach, I assume we
>>> will have to capture user consent claim by claim in this case similar to
>>> how we handle consent for scopes.
>>
>>
>> Yes we should use the same way to capture the consent claim by claim but
>> with the authorization request. Anyway we need to pass the 'openid' scope
>> along with the request in order to make this an oidc request right?
>>
> Yes, the specification specially mentions that.
> Yes, consent needs to captured with the authorization request as you
> mentioned. As the request object is a part of authorization request, we
> have to address it here. This section of specification [1] will help in
> understanding.
>
>>
>>
>> Are we introducing a new table to store this?
>>
>> I'm wondering whether we need to introduce a new table to store the
>> claims and consents with this implementation. Can't we use the same table
>> which we are introducing in consent management and then request consent,
>> claim by claim here as well?
>>
> The newly introducing tables to store consent are domain specific, as it
> comes for the solution. Consent for claims served by IS according to
> request object will need to be handled through IS data source as this
> governs what IS expose through userinfo endpoint and IDtoken.
>
>>
>>> We also need to take into the consideration that the request object can
>>> be signed(JWS) and we need to do the signature validation before it's
>>> handed over to next layer.
>>>
>>
>> +1. Yes we need to do.
>>
>>
>>> 1. Define custom claims for those and use claim retrieving
>>> extensions to handle the value
>>> 2. Provide an extension at this layer so that we filter out the
>>> claims handled by IS and seperate others to be handled in custom ways.
>>>
>>> +1 for option 2
>>
>> BTW, are we planing to implement consent management with IS 5.3.0 WUM
>> update? If so, can we do schema changes as a WUM update? Otherwise how do
>> we plan to release consent management feature?
>>
> Consent management we refer here is much specific to the domain. So that
> will not introduce a schema change to product db script. We will make use
> of the extension to be introduced at request object level and use the
> storage from solution.
>
> [1] - http://openid.net/specs/openid-connect-core-1_0.html#
> RequestParameter
>
>>
>> Thanks,
>>
>> Hasanthi Dissanayake
>>
>> Software Engineer | WSO2
>>
>> E: hasan...@wso2.com
>> M :0718407133 <071%20840%207133>| http://wso2.com <http://wso2.com/>
>>
>> On Wed, Oct 11, 2017 at 6:38 PM, Pushpalanka Jayawardhana <la...@wso2.com
>> > wrote:
>>
>>> Hi Hasanthi,
>>>
>>> On Wed, Oct 11, 2017 at 4:41 PM, Hasanthi Purnima Dissanayake <
>>> hasan...@wso2.com> wrote:
>>>
>>>>
>>>>
>>>> Hasanthi Dissanayake
>>>>
>>>> Software Engineer | WSO2
>>>>
>>>> E: hasan...@wso2.com
>>>> M :0718407133 <071%20840%207133>| http://wso2.com <http://wso2.com/>
>>>>
>>>> On Wed, Oct 11, 2017 at 4:35 PM, Hasanthi Purnima Dissanayake <
>>>> hasan...@wso2.com> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> In order to support 'Request Object' we need to support two parameters.
>>>>> 1. request parameter
>>>>> 2. request_uri parameter
>>>>>
>>>>>
>>>>>
>>>>> *1. request_parameter*
>>>>> The purpose of this parameter is for supporting to request some claims
>>>>> other than the default Userinfo and IdToken claim set which is associated
>>>>> with the requested scope.
>>>>>
>>>>> So if we consider a sample request with above parameter,
>>>>>
>>>>> https://localhost:9443/oauth2/authorize?
>>>>> response_type=code%20id_token
>>>>> &client_id=XXXXX
>>>>> &redirect_uri=http://localhost:8080/playground
>>>>> &scope=openid
>>>>> &state=af0ifjsldkj
>>>>> &nonce=n-0S6_WzA2Mj
>>>>> &request={
>>>>> "iss": "s6BhdRkqt3",
>>>>> "aud": "https://server.example.com";,
>>>>> "response_type": "code id_token",
>>>>> "client_id": "s6BhdRkqt3",
>>>>> "redirect_uri": "https://client.example.org/cb";,
>>>>> "scope": "openid",
>>>>> "state": "af0ifjsldkj",
>>>>> "nonce": "n-0S6_WzA2Mj",
>>>>> "max_age": 86400,
>>>>>
>>>>> "claims": {
>>>>> "userinfo": {
>>>>> "given_name": {
>>>>> "essential": true
>>>>> },
>>>>> "nickname": null,
>>>>> "email": {
>>>>> "essential": true
>>>>> },
>>>>>
>>>>> "id_token": {
>>>>> "gender": null,
>>>>> "birthdate": {
>>>>> "essential": true
>>>>> },
>>>>> "acr": {
>>>>> "values": [
>>>>> "urn:mace:incommon:iap:silver"
>>>>> ]
>>>>> }
>>>>> }
>>>>> }
>>>>> }
>>>>>
>>>>>
>>>>> The expected behavior of Identity server will be as follows.
>>>>>
>>>>> 1.Consider the claims "given_name" and "email" which are marked as
>>>>> 'essential:true' for 'userinfo' member. Even if they are not mapped with
>>>>> the openid scope in the registry, if these claims are requested claims,
>>>>> then 'given_name' and 'email' will be returned from the Userinfo endpoint.
>>>>> So as a summary the claims which have marked as 'essential : true' only
>>>>> get
>>>>> controlled by the requested claims and ignore the requested scopes. If the
>>>>> server can not provide those essential claims there wont be any failure or
>>>>> error message returning from the server.
>>>>>
>>>> Since scope concept is no longer effective in this approach, I assume
>>> we will have to capture user consent claim by claim in this case similar to
>>> how we handle consent for scopes. Are we introducing a new table to store
>>> this?
>>>
>>> We also need to take into the consideration that the request object can
>>> be signed(JWS) and we need to do the signature validation before it's
>>> handed over to next layer.
>>>
>>> Also in different domains the request object format get slightly
>>> modified. Additionally not all coming under claims will be delivered claims
>>> from IS user base. There can be disparate logics and sources to derive the
>>> values for this. To cater for this we have options,
>>>
>>> 1. Define custom claims for those and use claim retrieving
>>> extensions to handle the value
>>> 2. Provide an extension at this layer so that we filter out the
>>> claims handled by IS and seperate others to be handled in custom ways.
>>>
>>> Having option 2 will provide more freedom and efficient in handling
>>> cases where none of the incoming are claims handled directly from IS user
>>> base. Also it will let us handle any attributes introduced to outer layer
>>> from claims.
>>>
>>> Apart from mentioning 'essential:true', in different domains there can
>>> be cases where the claims become essential given a condition. For example:
>>> If user wish to have SMS OTP as an authentication factor then mobile number
>>> is essential. We can adopt such minor modifications by keeping
>>> extendability here.
>>>
>>>>
>>>>> 2. The claims like "nickname" it will act as a default claim and will
>>>>> control by both requested scopes and the requested claims.
>>>>>
>>>>> This behavior is common to the id token as well.
>>>>>
>>>>>
>>>>>
>>>>> *2. request_uri parameter*
>>>>> In this case the url will be a pre-registered url by the RP for use at
>>>>> the OP. The reference which is pointed from the url will consist the
>>>>> relevant jwt. The rationale behind returning claims will be same as the
>>>>> above in the request parameter.
>>>>>
>>>>
>>>>> As we are planning to provide the implementation as a 5.3.0 WUM update
>>>>> the 'acr' implementation will be not available there. So if 'acr' value is
>>>>> requested as an essential claim a pre-define value will be returned.
>>>>>
>>>> If we keep the extendability as mentioned above, we will be able to
>>> cater for this if an implementation become available in the future.
>>>
>>>>
>>>>> Any suggestion or feedback on the above will be highly appreciated.
>>>>>
>>>>
>>>>> Thanks,
>>>>>
>>>>> Hasanthi Dissanayake
>>>>>
>>>>> Software Engineer | WSO2
>>>>>
>>>>> E: hasan...@wso2.com
>>>>> M :0718407133 <071%20840%207133>| http://wso2.com <http://wso2.com/>
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Pushpalanka.
>>> --
>>> Pushpalanka Jayawardhana, B.Sc.Eng.(Hons).
>>> Senior Software Engineer, WSO2 Lanka (pvt) Ltd; wso2.com/
>>> Mobile: +94779716248
>>> Blog: pushpalankajaya.blogspot.com/ | LinkedIn: lk.linkedin.com/in/p
>>> ushpalanka/ | Twitter: @pushpalanka
>>>
>>>
>>
>
>
> --
> Pushpalanka.
> --
> Pushpalanka Jayawardhana, B.Sc.Eng.(Hons).
> Senior Software Engineer, WSO2 Lanka (pvt) Ltd; wso2.com/
> Mobile: +94779716248
> Blog: pushpalankajaya.blogspot.com/ | LinkedIn: lk.linkedin.com/in/
> pushpalanka/ | Twitter: @pushpalanka
>
>
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
