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 <sysad...@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.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