Hi Hasanthi, On Wed, Oct 11, 2017 at 4:35 PM, Hasanthi Purnima Dissanayake < [email protected]> 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: [email protected] > 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*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
