Hi Allen,<br><br>Validates looks fine! . I will make an in-depth study. <br>The third option you propose looks fine too and the more straightforward in some cases : If you've a doubt just ask the issuer. <br><br>It would work fine on some schemas. For example. If you're verifying user's name or dob and user is providing a X509 certificate containing those attributes you can check certificate status and request attributes to certificate issuer. <br>
<br>This will make Certification Authority implement an OpenID endpoint serving those kind of requests (the same way they're offering OCSP endpoints to deal with certificate status). <br>
<br>For attributes like email, or those that could be included inside a certificate or a signed assertion it would be "easy" to check with issuers the value of those attributes.<br><br>But there are attributes were it's value doesn't identify issuer, but only the owner. Attributes like for example mobile number where this number is not bound to any issuer. To verify this attribute we could send an SMS with a code and proceed to verify, but this should be performed by OP in order to keep complexity at minimum at RP, so we need to trust OP.<br>
<br>I strongly agree with you that it would be nice to have a trust relation made between RP and OP before starting attribute verification. To help establishing those relations it would be nice to have a way to determine the quality of an OP (f.ex reputation, mechanisms like what <a href="http://www.genghinieassociati.it/acrobat/it%20security/Standards/ETSI/tr_102030v010101p.pdf">TSL</a> is for Certification Authorities... in the end a set of white/black lists).<br>
<br>We currently have a service that allow RP to request users attributes like name, dob, social security number, mobile number, email and all in a secure way using verification tokens, X509 Certificates (using certificates from some European and South America countries)... . <br>
<br>We're using our own protocol but we strongly want to join OpenId and deprecate our current protocol. With AX verify and CX maybe we'll move to OpenId soon.<br><br>Many thanks Allen. I'll keep waiting Contract Exchange and hope we could help on the creation process.<br>
<br>Best regards<br><br>Dave<br><br><br><br><div class="gmail_quote">2009/6/3 Allen Tom <span dir="ltr"><<a href="mailto:atom@yahoo-inc.com" target="_blank">atom@yahoo-inc.com</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
Hi David,<br>
<br>
There has been a lot of discussion about adding Attribute Metadata to
AX 2.0, and this is within the charter of the proposed AX 2.0 Working
Group.<br>
<br>
<a href="http://wiki.openid.net/OpenID_Attribute_Exchange_Extension_2_0" target="_blank">http://wiki.openid.net/OpenID_Attribute_Exchange_Extension_2_0</a><br>
<br>
One of the primary use cases driving this is to enable an OP to
describe the user's email address. For instance, an email address
returned via AX could just be a user-entered string that is totally
unverified, or the email address could have been verified by the OP at
some point in the past. A third option is that the OP is actually the
user's email provider, and knows with 100% certainty that the user's
email address is correct.<br>
<br>
However, Trust is out of scope for AX 2.0. The RP would have to already
trust the OP to make claims about the validity of the user's attributes.<br>
<br>
The Contract Exchange WG is might be addressing your issue. I'm not
quite sure what the status is on CX.<br>
<a href="http://wiki.openid.net/Working_Groups%3AContract_Exchange_1" target="_blank">http://wiki.openid.net/Working_Groups%3AContract_Exchange_1</a><br>
<br>
Allen<br>
<br>
<br>
David Garcia wrote:
<blockquote type="cite"><div><div></div><div>My company is starting a new Identity Management Service
and we want to built it's AX interface over OpenId AX profile. <br>
<br>
I'll introduce myself at the very beginning. My name is Dave Garcia and
I'm working in a startup named Tractis in Spain. We have been offering
online contracts using digital signatures for some years. We want to
allow users to use third OPs to login in our site and we want to become
an OP too.<br>
<br>
Also we want to offer identity services some of them using attribute
exchange. We are dealing with attributes being asserted by users and
other are being certified by third parties (inside assertions,
X509certificates...). We want to make a difference between attributes
being asserted and those certified the same way authentication methods
have different assurance levels PAPE profile. <br>
<br>
Please let me paste here the briefing of what I'm talking about. <br>
<br>
Disclaimer : the following document is in a very early stage, comments
and suggestions are highly welcome. <br>
<br>
Many thanks for everybody reading :)<br>
<br>
Dave<br>
<br>
<h1>Short briefing for certified-AX profile for OpenId</h1>
<h1>Abstract</h1>
<p>Openid
AX profile for openid provides a way to exchange attributes between
relying parties and OP. Those attributes are simple key-value where the
keys are commonly agreed identifiers and values are encoded strings.
This approach works fine when dealing with "alegated attributes" like
email, name ... but a problem arises when we need to trust this
information ("certified attributes").</p>
<p>There are some
services that works fine using alegated identities but some specially
sensitive services, such as banking, don't. In these sensitive
scenarios, we need to ensure the quality/trustworthiness of those
attributes. Making a parallelism with existing open specs we need to
apply mechanisms analogous to those defined on the PAPE for OP
authentication but for attribute exchange.</p>
<p>From out
point of view, and regarding to this existent needs, it would be nice
to have those attributes scored using a commonly defined criteria so
when OP returns a certain set of attributes relying party could trust
them according to the score that OP gave them.</p>
<h2>Motivations</h2>
<p>Openid
is moving towards being the de facto standard for authentication on the
web. There are some other solutions to deal with attributes but it
would be nice to have a single technology, empowered by the use of
their plugins, to deal with identity.</p>
<h2>Scenario</h2>
<p>Here we'll expose an example of the messages exchanged
during certificate attributes fetching.</p>
<h2>Fetch</h2>
<h3>Relying party</h3>
<p>openid.ns.ax=<a href="http://openid.net/srv/ax/1.0" target="_blank">http://openid.net/srv/ax/1.0</a>
#To be redefined if a new release of the protocol is created</p>
<p>openid.ax.mode=fetch_request</p>
<p>openid.ax.type.age=<a href="http://axschema.org/birthDate" target="_blank">http://axschema.org/birthDate</a></p>
<p>openid.ax.update_url=<a href="http://idconsumer.com/update?transaction_id=a6b5c41" target="_blank">http://idconsumer.com/update?transaction_id=a6b5c41</a></p>
<h3>OpenidProvider</h3>
<p>openid.ns.ax=<a href="http://openid.net/srv/ax/1.0" target="_blank">http://openid.net/srv/ax/1.0</a>
openid.ax.mode=fetch_response</p>
<p>openid.ax.type.age=<a href="http://axschema.org/birthDate" target="_blank">http://axschema.org/birthDate</a></p>
<p>openid.ax.value.age=23</p>
<p> <b>openid.ax.score.age=3</b> </p>
<p> <b>openid.ax.receipt
= #Some kind of receipt certifying the methods used to certify the
attribute and that could be used for further processes</b> </p>
<p>openid.ax.update_url=<a href="http://idconsumer.com/update?transaction_id=a6b5c41" target="_blank">http://idconsumer.com/update?transaction_id=a6b5c41</a></p>
<h2>Store</h2>
<p>In
our approach OP deals with attribute certification processes :
validating certificates, contacting with attribute certification
authorities ... so there's no sense to allow the store of attributes
from others than OP.</p>
<p>Store is applied only to non certified attributes, this
is score 0.</p>
<h2>What are scores</h2>
<p>Scores
works in the same way PAPE levels does. They measure the way attributes
are certified and how the data being certified have been collected.</p>
<p>For example: attributes that have been gathered from a <i>qualified
certificate</i>
(according to EU Directive on electronic Signatures) that is stored
inside a SSCD the score will be 4 (means high). On the other hand, a
name that has been alegated in a web form will have the score 0, means
low.</p>
<p>Between 0 and 4 you have all the ways you can
certify an attribute from 0 (no certification) to 4. We made a brief
definition of the score concept that you could find here (<a href="https://www.tractis.com/tractis_score_policy" target="_blank">https://www.tractis.com/tractis_score_policy</a>)
and the mapping to real methods could be found here (<a href="https://www.tractis.com/tractis_score_policy" target="_blank">https://www.tractis.com/tractis_score_mapping</a>).
As we indicate in these documents, we (Tractis) have not invented
neither the classification nor the score policy but used previous work
by the NIST and EU.</p>
<h3>Problems to be solved</h3>
<p>In
Openid attributes are alegated, so you don't have to trust the OP
because there's nothing to trust on. Dealing with certified attributes
create a problem : how could I, as a relying party, know that this OP <b><i>works</i></b>
fine and if it says "level 4" all criteria to consider were done the
right way.</p>
<p>Our
proposal, in the same way as PAPE, the Relying Party does not need to
trust the OP. The User is the one that needs to trust the OP. If
problems arises with certain OP, then relying parties could choose to
use some OP and exclude others with mechanisms like white/black lists.</p>
<p>Other problem not covered is the format of the receipt
(attribute <b>openid.ax.receipt</b>).
Here we can proceed in 2 ways: (1) leaving this responsibility to
describe the message to the OP or (2) providing an spec about it.</p>
<p>Our proposition is: let this field being a signed
identifier holding the transaction ID for the given fetch request.</p>
<p>There
should be a way to connect this ID to the transaction performed on OP
(attribute fetching transaction) and to the information requested. OP
should make its best effort to handle as much evidences about the
process as possible including requested attributes, verified
information and returned response. But the detail of this evidential
information is out of the scope of this document.</p>
<br>
<br clear="all">
<br>
-- <br>
David Garcia<br>
CTO<br>
<br>
Tractis - Online contracts you can enforce<br>
<a href="http://www.tractis.com" target="_blank">http://www.tractis.com</a><br>
--<br>
Tel: (34) 93 551 96 60 (ext. 260) <br>
<br>
Email: <a href="mailto:david.garcia@tractis.com" target="_blank">david.garcia@tractis.com</a><br>
Blog: <a href="http://blog.negonation.com" target="_blank">http://blog.negonation.com</a><br>
Twitter: <a href="http://twitter.com/tractis" target="_blank">http://twitter.com/tractis</a><br>
</div></div><pre><hr size="4" width="90%">
_______________________________________________
specs mailing list
<a href="mailto:specs@openid.net" target="_blank">specs@openid.net</a>
<a href="http://openid.net/mailman/listinfo/specs" target="_blank">http://openid.net/mailman/listinfo/specs</a>
</pre>
</blockquote>
<br>
</div>
</blockquote></div><br><br clear="all"><br>-- <br>David Garcia<br>CTO<br><br>Tractis - Online contracts you can enforce<br><a href="http://www.tractis.com" target="_blank">http://www.tractis.com</a><br>--<br>Tel: (34) 93 551 96 60 (ext. 260) <br>
<br>Email: <a href="mailto:david.garcia@tractis.com" target="_blank">david.garcia@tractis.com</a><br>Blog: <a href="http://blog.negonation.com" target="_blank">http://blog.negonation.com</a><br>Twitter: <a href="http://twitter.com/tractis" target="_blank">http://twitter.com/tractis</a><br>