Some suggestions about Open Id AX profile

[David Garcia-6]

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 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). 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: [phone] (ext. 260)

Email: david.garcia@...
Blog: http://blog.negonation.com
Twitter: http://twitter.com/tractis

_______________________________________________
specs mailing list
specs@...
http://openid.net/mailman/listinfo/specs

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

[Allen Tom-2]

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 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). 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: [phone] (ext. 260)

Email: david.garcia@...
Blog: http://blog.negonation.com
Twitter: http://twitter.com/tractis

_______________________________________________
specs mailing list
specs@...
http://openid.net/mailman/listinfo/specs
  

_______________________________________________
specs mailing list
specs@...
http://openid.net/mailman/listinfo/specs

[David Garcia-6]

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 TSL is 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 <atom@...>

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 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). 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: [phone] (ext. 260)

Email: david.garcia@...
Blog: http://blog.negonation.com
Twitter: http://twitter.com/tractis

_______________________________________________
specs mailing list
specs@...
http://openid.net/mailman/listinfo/specs
  

--
David Garcia
CTO

Tractis - Online contracts you can enforce
http://www.tractis.com
--
Tel: [phone] (ext. 260)

Email: david.garcia@...
Blog: http://blog.negonation.com
Twitter: http://twitter.com/tractis

_______________________________________________
specs mailing list
specs@...
http://openid.net/mailman/listinfo/specs

[David Garcia-6]

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

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: [phone] (ext. 260)

Email: david.garcia@...
Blog: http://blog.negonation.com
Twitter: http://twitter.com/tractis

_______________________________________________
specs mailing list
specs@...
http://openid.net/mailman/listinfo/specs

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

[David Garcia-6]

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

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: [phone] (ext. 260)

Email: david.garcia@...
Blog: http://blog.negonation.com
Twitter: http://twitter.com/tractis

_______________________________________________
specs mailing list
specs@...
http://openid.net/mailman/listinfo/specs