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 OpenIdAbstract
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.
FetchRelying 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
Blog: http://blog.negonation.com
Twitter: http://twitter.com/tractis
_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
