backchannel/endpoint URLs, desired attributes

Chris Obdam chris.obdam at holder.nl
Tue Dec 15 18:20:24 UTC 2009


Peter,

See my comments below.

Op 15 dec 2009, om 18:54 heeft Peter Watkins het volgende geschreven:

> On Tue, Dec 15, 2009 at 06:35:18PM +0100, Chris Obdam wrote:
> 
>> In Holland we are going to work with the Attribute Exchange Validation Extension draft from tomorrow. The largest OP in Holland, Hyves (8 milion users) is going to support. We hope to find out what flaws there are in the current draft.
> 
> That is excellent news.
> 
>> We really need the meta data, verified_date. We are also trying to create a public list of validation method for each attribute.
>> Have you looked into http://step2.googlecode.com/svn/spec/attribute_exchange_validate/trunk/openid-attribute-exchange-validate-mode.html?
> 
> Yes, I have, and have commented on that draft:
> http://lists.openid.net/pipermail/openid-specs/2009-December/006189.html
> 
> Since there seems to be consensus regarding the importance of validation date,
> I'll just paste my comments on the other concern I have with that draft:
> 
> 2) The openid.ax.validation parameter purports to be about quality, but
>   the examples don't show the sort of options that Joseph A Holsten
>   suggested (Supplied by user vs. OP thinks this is the user's email vs.
>   the OP indemnifies the RP for any legal claims arising from the 
>   assertion being false). The examples show RPs specifying specific
>   means of verification (token_via_email, pin_via_sms) which sounds
>   both contentious (deciding which of two methods is stronger) and
>   difficult to manage (who maintains the enumerated lists of methods?
>   what happens if later research reveals a fundamental flaw in some
>   method, or infrastructure changes alter the value of some methods?).
>   I think it would be better to define the validation level as a 
>   number, and provide some guidance on what sort of current (i.e.
>   as of the date the spec is approved) validation methods should 
>   equate to certain levels.

But I don't the problem with specifying the means of verification. If the specified method  is flawed, another method should be defined?
If an OP uses an old method, the RP knows?

> There's always going to be a problem of
>   trust here, as anybody could set up an OP that claims with 100%
>   certaintly that my name is David Recordon. There will be a natural
>   tendency for RPs to whitelist trustworthy OPs, just as we've seen
>   whitelists of the PKI vendors we all depend on for our TLS/SSL certs.
That is certainly an issue. In Holland we are whitelisting the OP's at the moment.


>  So don't get bogged down in an exhaustive enumeration of methods
>   (I can just imagine providers of patended systems clamoring to
>   be listed) and an exhausting excercise of comparing methods (whose
>   PIN mailer is better?
> Is the US postal service more or less 
>   secure and trustworthy than the Swiss postal service?). Use general
>   examples and numeric scores.
If we only specify the means, the RP can always choose which one suits best?



More information about the specs mailing list