Hi David,
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.
http://wiki.openid.net/OpenID_Attribute_Exchange_Extension_2_0
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.
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.
The Contract Exchange WG is might be addressing your issue. I'm not
quite sure what the status is on CX.
http://wiki.openid.net/Working_Groups%3AContract_Exchange_1
Allen
David Garcia wrote:
My company is starting a new Identity Management Service and we want
to built it's AX interface over OpenId AX profile.
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.
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.
Please let me paste here the briefing of what I'm talking about.
Disclaimer : the following document is in a very early stage, comments
and suggestions are highly welcome.
Many thanks for everybody reading :)
Dave
Short briefing for certified-AX profile for OpenId
Abstract
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").
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.
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.
Motivations
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.
Scenario
Here we'll expose an example of the messages exchanged during
certificate attributes fetching.
Fetch
Relying party
openid.ns.ax=http://openid.net/srv/ax/1.0 #To be redefined if a new
release of the protocol is created
openid.ax.mode=fetch_request
openid.ax.type.age=http://axschema.org/birthDate
openid.ax.update_url=http://idconsumer.com/update?transaction_id=a6b5c41
OpenidProvider
openid.ns.ax=http://openid.net/srv/ax/1.0 openid.ax.mode=fetch_response
openid.ax.type.age=http://axschema.org/birthDate
openid.ax.value.age=23
*openid.ax.score.age=3*
*openid.ax.receipt = #Some kind of receipt certifying the methods used
to certify the attribute and that could be used for further processes*
openid.ax.update_url=http://idconsumer.com/update?transaction_id=a6b5c41
Store
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.
Store is applied only to non certified attributes, this is score 0.
What are scores
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.
For example: attributes that have been gathered from a /qualified
certificate/ (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.
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
(https://www.tractis.com/tractis_score_policy) and the mapping to real
methods could be found here
(https://www.tractis.com/tractis_score_mapping
<https://www.tractis.com/tractis_score_policy>). 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.
Problems to be solved
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
*/works/* fine and if it says "level 4" all criteria to consider were
done the right way.
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.
Other problem not covered is the format of the receipt (attribute
*openid.ax.receipt*). 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.
Our proposition is: let this field being a signed identifier holding
the transaction ID for the given fetch request.
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.
--
David Garcia
CTO
Tractis - Online contracts you can enforce
http://www.tractis.com
--
Tel: (34) 93 551 96 60 (ext. 260)
Email: david.gar...@tractis.com <mailto:david.gar...@tractis.com>
Blog: http://blog.negonation.com
Twitter: http://twitter.com/tractis
------------------------------------------------------------------------
_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
