<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>