Some suggestions about Open Id AX profile

David Garcia david.garcia at tractis.com
Wed Jun 3 21:02:46 UTC 2009


Hi Shade,

you're right describing the new drawbacks raised from the need of trust. I'm
proposing to move AX profile from a decentralized model where no trust is
needed to a "federated model" where trust relations exist between parties
(OPs and SPs).

With the current OpenId auth OPs' responsibility is to authenticate the user
and to interact  with the RP.  The main thing is to ensure that the user who
now authenticated is the same that authenticated every time but no matters
who this user is. With AX we care about who the user is and which are their
attributes but still in a very soft way. Now we want to go stronger (but
just in some cases).

In this "stronger" scenario the service contract is different so actors and
relations between them differ too creating this concept of trust between
parties.
If you are limited to work with those only you trust your freedom is reduced
to your federation partners so this implies that your users' freedom is
limited too .
This makes actors inside federations to create contracts between them and to
be audited to ensure their services are built and operated as "expected".

The big problem that I see is that this will raise up the entry barrier for
becoming an OP and moving AX from a distributed open mechanism to a
federated model. This kills some of the beautiful of Open Id but right now I
can't see another way of establishing this trust relations needed to operate
attributes with enough reliability (if we need more than user asserted
attributes).

About OAuth the second case I was proposing is quite similar to the OAuth 3
legged scenario, but I'm afraid the model I'm proposing is closer to a
broker pattern where users delegate trust issues to their OPs that to OAuth
(assuming I'm not an OAuth expert of course :) ). In this model if OPs
perform attribute exchange one of them should assume the requester role like
RP does.

Thanks for your accurate responses, I became really impressed by the high
quality of the list contributors :)

Best regards

Dave



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

> Score is not about the OP it's about the method used to gather the
>> attributes itself.
>>
>
> Which is good if you trust the OP to score itself.
>


>
>
>  In my opinion, and to keep things easy, trust should be binary I
>> [trust|don't trust] this OP.
>>
>
> For you as a Relying Party this seems workable; but since your users are
> placing their trust in *you*, while at the same time the actual entities
> they end up trusting are the OP's of those people they are forming/signing
> contracts with, this seems like an untenable position unless you can either
> restrict the OP (whitelist) to those you have verified (or had verified for
> you by a 3rd party *you* trust), which doesn't give users much freedom to
> select their OP's but does limit possible abuses, or fairly transfer
> responsibility for trust onto users.
>
>  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.
>>
>
> Except that A's OP isn't necessarily a RP; there is something called OAuth
> that might fit better here.
>
> -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/e37cf0b8/attachment.htm>


More information about the specs mailing list