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?

_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs

Reply via email to