Re: Some suggestions about Open Id AX profile

[David Garcia]

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 

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

Re: Some suggestions about Open Id AX profile

[SitG Admin]

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
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: 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 

> 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

Re: Some suggestions about Open Id AX profile

[David Garcia]

Hi Allen,

Validates looks fine!  . I will make an in-depth study.
The third option you propose looks fine too and the more straightforward in
some cases : If you've a doubt just ask the issuer.

It would work fine on some schemas. For example. If you're verifying user's
name or dob and user is providing a X509 certificate containing those
attributes you can check certificate status and request attributes to
certificate issuer.

This will make Certification Authority implement an OpenID endpoint serving
those kind of requests (the same way they're offering OCSP endpoints to deal
with certificate status).

For attributes like email, or those that could be included inside a
certificate or a signed assertion it would be "easy" to check with issuers
the value of those attributes.

But there are attributes were it's value doesn't identify issuer, but only
the owner. Attributes like for example mobile number where this number is
not bound to any issuer. To verify this attribute we could send an SMS with
a code and proceed to verify, but this should be performed by OP in order to
keep complexity at minimum at RP, so we need to trust OP.

I strongly agree with you that it would be nice to have a trust relation
made between RP and OP before starting attribute verification.  To help
establishing those relations it would be nice to have a way to determine the
quality of an OP (f.ex reputation, mechanisms like what
TSLis
for Certification Authorities... in the end a set of white/black
lists).

We currently have a service that allow RP to request users attributes like
name, dob, social security number, mobile number, email and all in a secure
way using verification tokens, X509 Certificates (using certificates from
some European and South America countries)... .

We're using our own protocol but we strongly want to join OpenId and
deprecate our current protocol. With AX verify and CX maybe we'll move to
OpenId soon.

Many thanks Allen. I'll keep waiting Contract Exchange and hope we could
help on the creation process.

Best regards

Dave



2009/6/3 Allen Tom 

>  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 pa

Re: Some suggestions about Open Id AX profile

[Allen Tom]

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 aleg

Re: Some suggestions about Open Id AX profile

[SitG Admin]

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
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs