Some suggestions about Open Id AX profile

[David Garcia]

Hi Shade,

thanks for your response. Maybe I explained myself wrong about scores, I'll
try to do it better this time .
Score is not about the OP it's about the method used to gather the
attributes itself. For example name recovered from authentication
certificate issued by a trusted certification authority inside a crypto
token scores 4, from a PKCS12 file scores 3 and alegated name scores 1
(quite simillar to levels defined by NIST, PAPE or the European Union
countries about authentication mechanisms).

In my opinion, and to keep things easy, trust should be binary I
[trust|don't trust] this OP.

As you said, keeping trust on a criteria based on statistics moves the trust
problem to a probabilistic problem about the chance of being cheated by the
provider I trust.

About AX and trust I think that there are (at least) 2 scenarios .


   - RP requesting attributes to people.
   - People requesting attributes to people.


The first one could be "solved" using CX profile (AFIK about the profile of
course, and that's not much ;) ).  Establishing a contract between parties
could create this trust between providers. The RP asks OP for an attribute,
if a trust relation exists (because a previous contract exists) attribute
value would be gathered from user information and returned to OP.

The second one is a little bit different because relation is between users.

User A wants to know the real name of person B. So he could ask B's OP for
it's name and as you say it will move the resposability of trusting to user
A... bad idea.

But what If (and this is only an early idea) user A asks it's OP saying , I
want to know B's name. So A's OP would then ask B's name to B's OP the same
way a RP would do.

If they've a contract regarding those kind of services requests will
succeed, otherwise it won't. This way you're moving the responsability of
trusting the other parties to your providers, that IMHO should be the ones
dealing with trust relations complexity and not the users theirselves. This
idea seems quite simillar to the federation between providers on other
protocols.

But as I said this idea is in a very early stage so I'll keep studying new
AX and CX in order to create a more robust proposal.

Many thanks Shade.

Dave

2009/6/2 SitG Admin <sysadmin at shadowsinthegarden.com>

> 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.
>>
>
> You can't. But you have the right idea:
>
>  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.
>>
>
> The user needs to trust the OP that the *other* user (the one they have a
> contract with) is using; so, share that information, and displace the
> responsibility for distrusting various claims onto the user. This isn't very
> *friendly*, mind you, but I don't see any way of preventing a user from
> setting up an absolutely new OP just for that one contract; with a valuable
> enough contract at stake, it would even be cost-effective to rig one's own
> "independent auditors".
>
> You might be able to score OP's locally, by "how many other contracts have
> trusted this OP", but then (to prevent gaming the system) there should be
> other statistics such as how long the OP has been in use, how often a
> contract has required "use another OP" during renegotiation, how often
> negotiations have *failed* entirely because one party refused to use another
> OP, the demographic spread of these uses over time, and maybe even the
> values of those contracts (for low-value contracts, there might not have
> been as much scrutiny over the trustworthiness of OP's), most or all of
> which raises user privacy issues. The last item raises verifiability issues;
> how do you *know* the value of the contracts are as reported?
>
> -Shade
>



-- 
David Garcia
CTO

Tractis - Online contracts you can enforce
http://www.tractis.com
--
Tel: (34) 93 551 96 60 (ext. 260)

Email: david.garcia at tractis.com
Blog: http://blog.negonation.com
Twitter: http://twitter.com/tractis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20090603/5067e519/attachment.htm>