[Openid-specs-ab] Definition of required and optional claims? Handling?

Henrik Biering hb at peercraft.com
Tue Apr 17 22:49:35 UTC 2012


For simple requirements the overall flow and user experience benefits 
from having the RP signal its requirements to the user directly on the 
consent page of the IDP.

If an RP offers more complex options, e.g. depending on nationality and 
type of credentials, I think it is much more flexible to let the RP 
handle the business logic itself before it sends the user to the IdP 
with the resulting simple set of requirements. This initial dialogue on 
the RP might even influence which IdP's the RP would trust and promote 
to the user.

Even if we had an extension to communicate more complex RP policies to 
an IdP, I expect it would often be missing some feature in practice.

=henrik


Den 16-04-2012 19:55, John Bradley skrev:
> I think it is best as an extension.  Adding parameters to the 
> individual attributes is probably all people can digest.
>
> Sent from my iPhone
>
> On 2012-04-16, at 7:48 PM, Pam Dingle <pdingle at pingidentity.com 
> <mailto:pdingle at pingidentity.com>> wrote:
>
>> How funny, I remember exactly these conversations happening in 
>> reference to information cards :)
>>
>> If we want an RP to be able to communicate "at least one of these 
>> three is required" to an IDP,  we have no choice but to add more 
>> vocabulary to the request object than just optional/required. I 
>> definitely see the need for this when it comes to EU regulatory 
>> requirements. My question is, does that sophisticated vocabulary have 
>> to be part of the base definition of the request object?  Or can it 
>> be an extension that is implemented only when those kinds of 
>> conversations are required?
>>
>> My preference would be to see this as an extension point.  That way 
>> describing such a policy language can have its own life and evolution.
>>
>>
>> On Fri, Apr 13, 2012 at 4:22 PM, Henrik Biering <hb at peercraft.com 
>> <mailto:hb at peercraft.com>> wrote:
>>
>>     Technically, Yes!
>>
>>     But the problem is that such differences in RP policy are neither
>>     clear to the IdP - nor the user before it is too late.
>>
>>     The IdP would loose the ability to provide a consistent
>>     experience to its users. Sometimes users will need to check every
>>     proposed userinfo item to continue their intended process as
>>     planned when they are returned to the RP. Sometimes they will
>>     only need to check say 3 out of 10 items, where the IDP has no
>>     means of indicating which ones are really required. And sometimes
>>     (when the RP is using the required/optional selection as
>>     intended) the IDP will be able to highlight which items are
>>     required.
>>
>>     So the user experience becomes terrible. The standard fast track
>>     will be to always "Check all" (with fake info if needed), while
>>     honest privacy aware users will have a nightmare finding out what
>>     is really required to proceed with their intended purpose.
>>
>>     This again means that we will easily get in trouble with the
>>     various privacy regulations that Nat mentioned previously in this
>>     thread.
>>
>>     =henrik
>>
>>     Den 13-04-2012 22:32, Pam Dingle skrev:
>>>     Isn't it the case that Relying Parties can build in their own
>>>     flexibility if they need to, by making all the claims optional?
>>>      In doing so, they Relying Party essentially takes over all
>>>     responsibility for the quality and content of the claims, and
>>>     the Identity Provider has no obligation to care whether the
>>>     claims are populated or not.  The RP can still send a user to an
>>>     error page, but does so according to their own business logic,
>>>     once the user is back under RP control.
>>>
>>>
>>>
>>>     On Fri, Apr 13, 2012 at 8:34 AM, Henrik Biering
>>>     <hb at peercraft.com <mailto:hb at peercraft.com>> wrote:
>>>
>>>         I do not agree that the IdP must decline authentication
>>>         based on a userinfo policy conflict between the client and
>>>         the user. The IdP should not break the interaction between
>>>         the client and the user as long as the user gives his
>>>         consent to (1) Authentication by logging in, and (2)
>>>         Authorization to being redirected back to the client with
>>>         the standard protocol flow. The standard flow should only be
>>>         aborted if the user cancels or otherwise fails to complete
>>>         these two basic actions.
>>>
>>>         This is clearly supported by these statements in Messages
>>>         2.1.2.1 <http://2.1.2.1>:
>>>
>>>         ... OpenID Providers MAY ignore requests for Claims they
>>>         cannot provide or do not understand
>>>
>>>         ... *_Relying Parties_* MAY also consider it an error
>>>         condition if all requested required Claims are not provided.
>>>
>>>         The latter statement presupposes that the Client receives
>>>         specific information about which required claims were not
>>>         provided. And in any case that this decision is up to the
>>>         Client rather than the IdP.
>>>
>>>         Government sites may without any consideration want users
>>>         redirected to gotoprison.gov <http://gotoprison.gov> or
>>>         findanothercountry.me <http://findanothercountry.me> if
>>>         users do not do exactly what they are being requested to.
>>>
>>>         But contrary, a typical business use-case requires a more
>>>         flexible approach. E.g. when a user wants to sign up for a
>>>         postpaid service:
>>>
>>>         1) The client asks for verified email, and full name,
>>>         birthdate and address.
>>>         2) The client promotes some leading email providers for
>>>         authentication
>>>         3) The user chooses an account that he logs into frequently
>>>         (but has not trusted with his proper birthday and address).
>>>         4) After authentication the user returns to the Client with
>>>         a verified email and possibly his name.
>>>         5) The client says "sorry - no postpaid service for you" BUT
>>>         ALSO (because markets are conversations) "here are some
>>>         alternative options based on the information you provided"
>>>
>>>         By aborting the authentication/authorization before the user
>>>         returns to the Client, you will be depriving the client and
>>>         user the option of directly continuing a proper business
>>>         focused dialogue on the basis of what the user has actually
>>>         consented to. E.g in the above use-case:
>>>
>>>         1) The user may enter the remaining required info at the
>>>         client to qualify for the postpaid service.
>>>         2) The user may access the corrosponding prepaid service
>>>         using a range of prepayment options.
>>>         3) The user may signup - without further email validation -
>>>         to the client's newsletters.
>>>         4) The user may send the client personal RFP's using
>>>         VRM-Tool XYZ
>>>
>>>         =henrik
>>>
>>>         Den 13-04-2012 07:25, John Bradley skrev:
>>>>         The spec is not requiring an error to the user.  It is saying that the IdP can't send a positive authentication without the required claims.
>>>>
>>>>         The IdP must decline the authentication.
>>>>
>>>>         John
>>>>         On 2012-04-13, at 2:25 AM, Henrik Biering wrote:
>>>>
>>>>>         I strongly disagree in treating a missing required claim as an error!
>>>>>
>>>>>         The ability to distinguish between required and optional claims is definitely useful for the IdP in order to clearly convey the clients policy for a specific action to the user.  However, if the user disagrees with this policy - or have chosen to use another provider for some claims - it is a pure policy dispute matter that can only be resolved through a direct dialogue between the client and the user. Policy dispute resolution should be outside the scope of the protocol.
>>>>>
>>>>>         One of the worst general implementation errors in OpenID 1 and 2 has been throwing unintelligible technical error messages in the ordinary users face. So instead of further hinting developers to treat policy disputes as technical errors, it may be relevant to add informative notes as to when developers should consult  their business responsible colleagues about relevant options and user dialogue.
>>>>>
>>>>>         =henrik
>>>>>
>>>>>         Den 11-04-2012 22:14, Mike Jones skrev:
>>>>>>         If a required claim isn't available, that's an error.  (It's not for optional claims.)  But looking at the list of errors in 2.1.4http://openid.net/specs/openid-connect-messages-1_0-09.html#anchor8  we haven't defined an error for that case.  I suspect we should define one like "required_claim_unavailable".
>>>>>>
>>>>>>         What are other's thoughts?
>>>>>>
>>>>>>         				-- Mike
>>>>>>
>>>>>>         -----Original Message-----
>>>>>>         From:openid-specs-ab-bounces at lists.openid.net  <mailto:openid-specs-ab-bounces at lists.openid.net>  [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Vladimir Dzhuvinov / NimbusDS
>>>>>>         Sent: Wednesday, April 11, 2012 2:36 AM
>>>>>>         To:openid-specs-ab at lists.openid.net  <mailto:openid-specs-ab at lists.openid.net>
>>>>>>         Subject: [Openid-specs-ab] Definition of required and optional claims? Handling?
>>>>>>
>>>>>>         Several places in spec (mostly on the OpenID request object) mention "required claim" and "optional claim". I was kind of wondering what exactly these are until I read section 5.1.3 on handling "acr" claim requests.
>>>>>>
>>>>>>         http://openid.net/specs/openid-connect-messages-1_0-09.html#req.obj.veri
>>>>>>
>>>>>>         Would it make sense to define "required claim" and "optional claim" in a separate section? Also their handling, if it can be generalised?
>>>>>>
>>>>>>         Right now I'm not sure about the difference between required and optional UserInfo claim requests. How is a required UserInfo claim request to be handled if the data isn't available on the server?
>>>>>>
>>>>>>         Cheers,
>>>>>>
>>>>>>         Vladimir
>>>>>>         --
>>>>>>         Vladimir Dzhuvinov :www.NimbusDS.com  <http://www.NimbusDS.com>  :vladimir at nimbusds.com  <mailto:vladimir at nimbusds.com>
>>>>>>
>>>>>>         _______________________________________________
>>>>>>         Openid-specs-ab mailing list
>>>>>>         Openid-specs-ab at lists.openid.net  <mailto:Openid-specs-ab at lists.openid.net>
>>>>>>         http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>>
>>>>>>
>>>>>>         _______________________________________________
>>>>>>         Openid-specs-ab mailing list
>>>>>>         Openid-specs-ab at lists.openid.net  <mailto:Openid-specs-ab at lists.openid.net>
>>>>>>         http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>>
>>>>>         _______________________________________________
>>>>>         Openid-specs-ab mailing list
>>>>>         Openid-specs-ab at lists.openid.net  <mailto:Openid-specs-ab at lists.openid.net>
>>>>>         http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>
>>>         _______________________________________________
>>>         Openid-specs-ab mailing list
>>>         Openid-specs-ab at lists.openid.net
>>>         <mailto:Openid-specs-ab at lists.openid.net>
>>>         http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>
>>>
>>>
>>>
>>>     -- 
>>>     *Pamela Dingle*  | Sr. Technical Architect
>>>     *Ping**Identity*  | www.pingidentity.com
>>>     <http://www.pingidentity.com>
>>>     - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>>>     - - - - - - - -
>>>     *O:* 303-999-5890 <tel:303-999-5890> *M:* 303-999-5890
>>>     <tel:303-999-5890>
>>>     *Email:* pdingle at pingidentity.com <mailto:pdingle at pingidentity.com>
>>>     - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>>>     - - - - - - - -
>>>     *Connect with Ping*
>>>     Twitter: @pingidentity
>>>     LinkedIn Group: Ping's Identity Cloud
>>>     Facebook.com/pingidentitypage <http://Facebook.com/pingidentitypage>
>>>     	
>>>     *Connect with me*
>>>     Twitter: @pamelarosiedee
>>>
>>>
>>
>>
>>
>> -- 
>> *Pamela Dingle*  | Sr. Technical Architect
>> *Ping**Identity*  | www.pingidentity.com <http://www.pingidentity.com>
>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
>> - - - - -
>> *O:* 303-999-5890 *M:* 303-999-5890
>> *Email:* pdingle at pingidentity.com <mailto:pdingle at pingidentity.com>
>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
>> - - - - -
>> *Connect with Ping*
>> Twitter: @pingidentity
>> LinkedIn Group: Ping's Identity Cloud
>> Facebook.com/pingidentitypage <http://Facebook.com/pingidentitypage>
>> 	
>> *Connect with me*
>> Twitter: @pamelarosiedee
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120418/ce932fdc/attachment-0001.html>


More information about the Openid-specs-ab mailing list