<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body 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 2.1.2.1:<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 gotoprison.gov or findanothercountry.me 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:
<blockquote
cite="mid:D78F2BF9-5D56-41C7-9509-C0712343B083@ve7jtb.com"
type="cite">
<pre wrap="">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 wrap="">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 wrap="">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 class="moz-txt-link-freetext" href="http://openid.net/specs/openid-connect-messages-1_0-09.html#anchor8">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 class="moz-txt-link-abbreviated" href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a> [<a class="moz-txt-link-freetext" href="mailto:openid-specs-ab-bounces@lists.openid.net">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 class="moz-txt-link-abbreviated" href="mailto:openid-specs-ab@lists.openid.net">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 class="moz-txt-link-freetext" href="http://openid.net/specs/openid-connect-messages-1_0-09.html#req.obj.veri">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 class="moz-txt-link-abbreviated" href="http://www.NimbusDS.com">www.NimbusDS.com</a> : <a class="moz-txt-link-abbreviated" href="mailto:vladimir@nimbusds.com">vladimir@nimbusds.com</a>
_______________________________________________
Openid-specs-ab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
_______________________________________________
Openid-specs-ab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
<pre wrap="">_______________________________________________
Openid-specs-ab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
</body>
</html>