<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body 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:
<blockquote
cite="mid:CANBMvsArQ9OvxJ1dSvYtzkKiKyomAFSMdHVmewGkiUp2ypfZ6w@mail.gmail.com"
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">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 class="h5">
<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">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 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">Facebook.com/pingidentitypage</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>
</body>
</html>