Hi Hasanthi, On Tue, Jan 23, 2018 at 10:59 AM, Johann Nallathamby <joh...@wso2.com> wrote:
> Hi Hasanthi, > > On Tue, Jan 23, 2018 at 9:31 AM, Hasanthi Purnima Dissanayake < > hasan...@wso2.com> wrote: > >> Hi Johann, >> >> Is there any instance in which IS will throw error to client because it >>> cannot send the claim? >>> >>> Because in the spec it says the following. >>> >>> Note that even if the Claims are not available because the End-User did >>> not authorize their release or they are not present, the Authorization >>> Server MUST NOT generate an error when Claims are not returned, whether >>> they are Essential or Voluntary, unless otherwise specified in the >>> description of the specific claim. >>> >>> So IMO we need to have a property for each claim that says whether we >>> return an error or not. >>> >>> Wdyt? >>> >> >> What I understand from the above is, if a claim is marked as essential or >> voluntary and if the server can not return the claim the flow should not >> break and server should not throw an error if it is not specially specified >> in the server side. In this scope we don't specify this from server side. >> Though this is not a MUST we can add this as an improvement as it adds a >> value. >> > > So IIUC in any circumstance we don't send an error to client. Correct? > > Yes, we can add that property as an improvement. > >> >> >>>> 2. The claims like "nickname" it will act as a default claim and will >>>> control by both requested scopes and the requested claims. >>>> >>> >>> What do you mean by controlling using requested scope? Do you mean if >>> the client doesn't request at least one scope that includes this claim we >>> won't return that claim? I don't think that is mentioned in the spec. Can >>> you clarify? >>> >> >> The spec does not directly specify how should we treat for the Voluntary >> Claim from the server side. So what we have planned to do is to honour the >> scopes and server level requested claims when returning this claim. >> > > IMO, because the spec doesn't say to do anything special on the OP side > about not being able to release a particular claim (it says not to break > the normal flow), there is nothing special we can differentiate between > essential and voluntary claims. Only thing we may be able to do is, give a > warning to user saying that if s/he doesn't approve an essential claim s/he > won't be able to work with the application smoothly. We can't do anything > beyond that right? > > When you say scopes which scopes are you referring to? Are they the > requested scopes in the request or the defined scopes in the registry? I > fail to understand what scopes have to do with claims in this case. > Following is what I find in spec related to this. > > "It is also the only way to request specific combinations of the standard > Claims that cannot be specified using scope values. " > > As I understand if the specific requested OIDC claim, is defined in the > OIDC dialect, the user has a value for that claim and s/he has approved > that claim for the RP, then we can send them to the RP, regardless of > whether it is defined in scope or not. Otherwise we are contradicting the > above statement right? > Any idea why we are checking scopes here? Regards, Johann. > > Also regarding requested claims in service provider configuration, IIRC we > used it as a way to control access to certain claims by service providers, > which overrides the requested scopes and requested claims. *But that > is only if the requested claims list is not empty in service provider > configuration*. I.e. requested claims in service provider configuration > must have at least 1 claim. Otherwise what will happen is for every service > provider we need to add all the OIDC claims if they are going to request > claims dynamically, using scopes or requested claims in the request. Do I > make sense or am I missing something? > > Regards, > Johann. > > >> Thanks, >> >> >> On Tue, Jan 23, 2018 at 9:05 AM, Johann Nallathamby <joh...@wso2.com> >> wrote: >> >>> Hi Hasanthi, >>> >>> 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. >>>> >>> >>> Is there any instance in which IS will throw error to client because it >>> cannot send the claim? >>> >>> Because in the spec it says the following. >>> >>> Note that even if the Claims are not available because the End-User did >>> not authorize their release or they are not present, the Authorization >>> Server MUST NOT generate an error when Claims are not returned, whether >>> they are Essential or Voluntary, unless otherwise specified in the >>> description of the specific claim. >>> >>> So IMO we need to have a property for each claim that says whether we >>> return an error or not. >>> >>> Wdyt? >>> >>> >>>> >>>> 2. The claims like "nickname" it will act as a default claim and will >>>> control by both requested scopes and the requested claims. >>>> >>> >>> What do you mean by controlling using requested scope? Do you mean if >>> the client doesn't request at least one scope that includes this claim we >>> won't return that claim? I don't think that is mentioned in the spec. Can >>> you clarify? >>> >>> Regards, >>> Johann. >>> >>> >>>> 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. >>>> >>>> Any suggestion or feedback on the above will be highly appreciated. >>>> >>>> Thanks, >>>> >>>> Hasanthi Dissanayake >>>> >>>> Software Engineer | WSO2 >>>> >>>> E: hasan...@wso2.com >>>> M :0718407133| http://wso2.com <http://wso2.com/> >>>> >>> >>> >>> >>> -- >>> >>> *Johann Dilantha Nallathamby* >>> Senior Lead Solutions Engineer >>> WSO2, Inc. >>> lean.enterprise.middleware >>> >>> Mobile: *+94 77 7776950* >>> LinkedIn: *http://www.linkedin.com/in/johann-nallathamby >>> <http://www.linkedin.com/in/johann-nallathamby>* >>> Medium: *https://medium.com/@johann_nallathamby >>> <https://medium.com/@johann_nallathamby>* >>> Twitter: *@dj_nallaa* >>> >> >> >> >> -- >> >> Hasanthi Dissanayake >> >> Senior Software Engineer | WSO2 >> >> E: hasan...@wso2.com >> M :0718407133| http://wso2.com <http://wso2.com/> >> > > > > -- > > *Johann Dilantha Nallathamby* > Senior Lead Solutions Engineer > WSO2, Inc. > lean.enterprise.middleware > > Mobile: *+94 77 7776950* > LinkedIn: *http://www.linkedin.com/in/johann-nallathamby > <http://www.linkedin.com/in/johann-nallathamby>* > Medium: *https://medium.com/@johann_nallathamby > <https://medium.com/@johann_nallathamby>* > Twitter: *@dj_nallaa* > -- *Johann Dilantha Nallathamby* Senior Lead Solutions Engineer WSO2, Inc. lean.enterprise.middleware Mobile: *+94 77 7776950* LinkedIn: *http://www.linkedin.com/in/johann-nallathamby <http://www.linkedin.com/in/johann-nallathamby>* Medium: *https://medium.com/@johann_nallathamby <https://medium.com/@johann_nallathamby>* Twitter: *@dj_nallaa*
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
