<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    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. <br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    =henrik<br>
    <div class="moz-signature"><br>
      <font face="Verdana, sans-serif"><font color="#000000"><font
            size="2"></font></font></font></div>
    <br>
    Den 16-04-2012 19:55, John Bradley skrev:
    <blockquote
      cite="mid:C4BBD749-5FE5-4C22-9928-D3669A9177DB@ve7jtb.com"
      type="cite">
      <div>I think it is best as an extension.  Adding parameters to the
        individual attributes is probably all people can digest. <br>
        <br>
        Sent from my iPhone</div>
      <div><br>
        On 2012-04-16, at 7:48 PM, Pam Dingle <<a
          moz-do-not-send="true" href="mailto:pdingle@pingidentity.com">pdingle@pingidentity.com</a>>
        wrote:<br>
        <br>
      </div>
      <blockquote type="cite">
        <div>How funny, I remember exactly these conversations happening
          in reference to information cards :)
          <div><br>
          </div>
          <div>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?   </div>
          <div><br>
          </div>
          <div>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.  </div>
          <div><br>
          </div>
          <div><br>
            <div class="gmail_quote">On Fri, Apr 13, 2012 at 4:22 PM,
              Henrik Biering <span dir="ltr"><<a
                  moz-do-not-send="true" href="mailto:hb@peercraft.com">hb@peercraft.com</a>></span>
              wrote:<br>
              <blockquote class="gmail_quote" style="margin:0 0 0
                .8ex;border-left:1px #ccc solid;padding-left:1ex">
                <div bgcolor="#FFFFFF" text="#000000"> Technically, Yes!<br>
                  <br>
                  But the problem is that such differences in RP policy
                  are neither clear to the IdP - nor the user before it
                  is too late.<br>
                  <br>
                  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. <br>
                  <br>
                  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.<br>
                  <br>
                  This again means that we will easily get in trouble
                  with the various privacy regulations that Nat
                  mentioned previously in this thread.<br>
                  <br>
                  =henrik<br>
                  <br>
                  Den 13-04-2012 22:32, Pam Dingle skrev:
                  <div>
                    <div class="h5">
                      <blockquote type="cite">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.
                        <div>
                          <div><br>
                          </div>
                          <div><br>
                            <br>
                            <div class="gmail_quote">On Fri, Apr 13,
                              2012 at 8:34 AM, Henrik Biering <span
                                dir="ltr"><<a moz-do-not-send="true"
                                  href="mailto:hb@peercraft.com"
                                  target="_blank">hb@peercraft.com</a>></span>
                              wrote:<br>
                              <blockquote class="gmail_quote"
                                style="margin:0 0 0 .8ex;border-left:1px
                                #ccc solid;padding-left:1ex">
                                <div bgcolor="#FFFFFF" text="#000000"> 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.<br>
                                  <br>
                                  This is clearly supported by these
                                  statements in Messages <a
                                    moz-do-not-send="true"
                                    href="http://2.1.2.1"
                                    target="_blank">2.1.2.1</a>:<br>
                                  <br>
                                  ... OpenID Providers MAY ignore
                                  requests for Claims they cannot
                                  provide or do not understand<br>
                                  <br>
                                  ... <b><u>Relying Parties</u></b> MAY
                                  also consider it an error condition if
                                  all requested required Claims are not
                                  provided.<br>
                                  <br>
                                  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.<br>
                                  <br>
                                  Government sites may without any
                                  consideration want users redirected to
                                  <a moz-do-not-send="true"
                                    href="http://gotoprison.gov"
                                    target="_blank">gotoprison.gov</a>
                                  or <a moz-do-not-send="true"
                                    href="http://findanothercountry.me"
                                    target="_blank">findanothercountry.me</a>
                                  if users do not do exactly what they
                                  are being requested to.<br>
                                  <br>
                                  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:<br>
                                  <br>
                                  1) The client asks for verified email,
                                  and full name, birthdate and address.<br>
                                  2) The client promotes some leading
                                  email providers for authentication<br>
                                  3) The user chooses an account that he
                                  logs into frequently (but has not
                                  trusted with his proper birthday and
                                  address).<br>
                                  4) After authentication the user
                                  returns to the Client with a verified
                                  email and possibly his name.<br>
                                  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"<br>
                                  <br>
                                  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:<br>
                                  <br>
                                  1) The user may enter the remaining
                                  required info at the client to qualify
                                  for the postpaid service.<br>
                                  2) The user may access the
                                  corrosponding prepaid service using a
                                  range of prepayment options.<br>
                                  3) The user may signup - without
                                  further email validation - to the
                                  client's newsletters.<br>
                                  4) The user may send the client
                                  personal RFP's using VRM-Tool XYZ<br>
                                  <br>
                                  =henrik<br>
                                  <br>
                                  Den 13-04-2012 07:25, John Bradley
                                  skrev:
                                  <div>
                                    <div>
                                      <blockquote type="cite">
                                        <pre>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:

</pre>
                                        <blockquote type="cite">
                                          <pre>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:
</pre>
                                          <blockquote type="cite">
                                            <pre>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.4 <a moz-do-not-send="true" href="http://openid.net/specs/openid-connect-messages-1_0-09.html#anchor8" target="_blank">http://openid.net/specs/openid-connect-messages-1_0-09.html#anchor8</a> 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: <a moz-do-not-send="true" href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">openid-specs-ab-bounces@lists.openid.net</a> [<a moz-do-not-send="true" href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">mailto:openid-specs-ab-bounces@lists.openid.net</a>] On Behalf Of Vladimir Dzhuvinov / NimbusDS
Sent: Wednesday, April 11, 2012 2:36 AM
To: <a moz-do-not-send="true" href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>
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.

<a moz-do-not-send="true" href="http://openid.net/specs/openid-connect-messages-1_0-09.html#req.obj.veri" target="_blank">http://openid.net/specs/openid-connect-messages-1_0-09.html#req.obj.veri</a>

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 : <a moz-do-not-send="true" href="http://www.NimbusDS.com" target="_blank">www.NimbusDS.com</a> : <a moz-do-not-send="true" href="mailto:vladimir@nimbusds.com" target="_blank">vladimir@nimbusds.com</a>

_______________________________________________
Openid-specs-ab mailing list
<a moz-do-not-send="true" href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a>
<a moz-do-not-send="true" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>


_______________________________________________
Openid-specs-ab mailing list
<a moz-do-not-send="true" href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a>
<a moz-do-not-send="true" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>

</pre>
                                          </blockquote>
                                          <pre>_______________________________________________
Openid-specs-ab mailing list
<a moz-do-not-send="true" href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a>
<a moz-do-not-send="true" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
                                        </blockquote>
                                      </blockquote>
                                    </div>
                                  </div>
                                </div>
                                <br>
_______________________________________________<br>
                                Openid-specs-ab mailing list<br>
                                <a moz-do-not-send="true"
                                  href="mailto:Openid-specs-ab@lists.openid.net"
                                  target="_blank">Openid-specs-ab@lists.openid.net</a><br>
                                <a moz-do-not-send="true"
                                  href="http://lists.openid.net/mailman/listinfo/openid-specs-ab"
                                  target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
                                <br>
                              </blockquote>
                            </div>
                            <br>
                            <br clear="all">
                            <div><br>
                            </div>
                            -- <br>
                            <span><font
                                style="color:rgb(52,54,52);font-size:12px"
                                color="#343634" face="Tahoma"><strong><span>Pamela
                                    Dingle</span></strong>  |  <span>Sr.
                                  Technical Architect</span></font><br>
                              <font style="font-size:11px" face="Arial"><font
                                  color="#343634" face="Tahoma"><strong>Ping</strong></font><font
                                  color="#E71939" face="Tahoma"><strong>Identity</strong></font>  |  

                                <a moz-do-not-send="true"
                                  href="http://www.pingidentity.com"
                                  target="_blank">www.pingidentity.com</a><br>
                                - - - - - - - - - - - - - - - - - - - -
                                - - - - - - - - - - - - - - - - - - - -<br>
                                <font color="#005568"><strong>O:</strong></font> <font
                                  color="#343634"><span><a
                                      moz-do-not-send="true"
                                      href="tel:303-999-5890"
                                      value="+13039995890"
                                      target="_blank">303-999-5890</a></span></font>   <font
                                  color="#005568"><strong>M:</strong></font> <font
                                  color="#343634"><span><a
                                      moz-do-not-send="true"
                                      href="tel:303-999-5890"
                                      value="+13039995890"
                                      target="_blank">303-999-5890</a></span></font><br>
                                <font color="#005568"><strong>Email:</strong></font> <span><a
                                    moz-do-not-send="true"
                                    href="mailto:pdingle@pingidentity.com"
                                    target="_blank">pdingle@pingidentity.com</a></span><br>
                                - - - - - - - - - - - - - - - - - - - -
                                - - - - - - - - - - - - - - - - - - - -<br>
                                <table cellpadding="0" cellspacing="0">
                                  <tbody>
                                    <tr valign="top">
                                      <td nowrap="nowrap">
                                        <div style="float:left"><font
                                            style="font-size:11px"
                                            face="Arial"><font
                                              color="#005568"><strong>Connect
                                                with Ping</strong></font><br>
                                            <font color="#000000">Twitter:
                                              @pingidentity</font><br>
                                            <font color="#000000">LinkedIn
                                              Group: Ping's Identity
                                              Cloud</font>    <br>
                                            <font color="#000000"><a
                                                moz-do-not-send="true"
                                                href="http://Facebook.com/pingidentitypage">Facebook.com/pingidentitypage</a></font></font></div>
                                      </td>
                                      <td nowrap="nowrap">
                                        <div style="margin-left:20px"><font
                                            style="font-size:11px"
                                            face="Arial"><font
                                              color="#005568"><strong><span>Connect
                                                  with me</span></strong></font><br>
                                            <font color="#000000"><span>Twitter:

                                                @pamelarosiedee</span></font><br>
                                            <font color="#000000"><span></span></font></font></div>
                                      </td>
                                    </tr>
                                  </tbody>
                                </table>
                              </font></span><br>
                          </div>
                        </div>
                      </blockquote>
                    </div>
                  </div>
                </div>
              </blockquote>
            </div>
            <br>
            <br clear="all">
            <div><br>
            </div>
            -- <br>
            <span style="font-family:'Lucida
Grande',Tahoma,Arial,Verdana,sans-serif;font-size:10px;color:rgb(42,42,42)"><font
                style="color:rgb(52,54,52);font-size:12px"
                color="#343634" face="Tahoma"><strong><span>Pamela
                    Dingle</span></strong>  |  <span>Sr. Technical
                  Architect</span></font><br>
              <font style="font-size:11px" face="Arial"><font
                  color="#343634" face="Tahoma"><strong>Ping</strong></font><font
                  color="#E71939" face="Tahoma"><strong>Identity</strong></font>  |  
                <a moz-do-not-send="true"
                  href="http://www.pingidentity.com" target="_blank">www.pingidentity.com</a><br>
                - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                - - - - - - - - - - - -<br>
                <font color="#005568"><strong>O:</strong></font> <font
                  color="#343634"><span>303-999-5890</span></font>   <font
                  color="#005568"><strong>M:</strong></font> <font
                  color="#343634"><span>303-999-5890</span></font><br>
                <font color="#005568"><strong>Email:</strong></font> <span><a
                    moz-do-not-send="true"
                    href="mailto:pdingle@pingidentity.com"
                    target="_blank">pdingle@pingidentity.com</a></span><br>
                - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                - - - - - - - - - - - -<br>
                <table cellpadding="0" cellspacing="0">
                  <tbody>
                    <tr valign="top">
                      <td nowrap="nowrap">
                        <div style="float:left"><font
                            style="font-size:11px" face="Arial"><font
                              color="#005568"><strong>Connect with Ping</strong></font><br>
                            <font color="#000000">Twitter: @pingidentity</font><br>
                            <font color="#000000">LinkedIn Group: Ping's
                              Identity Cloud</font>    <br>
                            <font color="#000000"><a
                                moz-do-not-send="true"
                                href="http://Facebook.com/pingidentitypage">Facebook.com/pingidentitypage</a></font></font></div>
                      </td>
                      <td nowrap="nowrap">
                        <div style="margin-left:20px"><font
                            style="font-size:11px" face="Arial"><font
                              color="#005568"><strong><span>Connect with
                                  me</span></strong></font><br>
                            <font color="#000000"><span>Twitter:
                                @pamelarosiedee</span></font><br>
                            <font color="#000000"><span></span></font></font></div>
                      </td>
                    </tr>
                  </tbody>
                </table>
              </font></span><br>
          </div>
        </div>
      </blockquote>
    </blockquote>
  </body>
</html>