[security] Username / password etc. is out of scope for OpenID

[Eddy Nigg (StartCom Ltd.)]

OK, so what do we have in the draft:


      /Abstract/

/ OpenID Authentication provides a way to prove that an End User owns an
Identifier. It does this without the Relying Party needing access to
password, email address, or other sensitive information.
/

*This means, that instead of providing a user name, email and password,
the RP receives an identifier and prove of possession from the end user
(actually not from the end user, but from the IDP). Now comes the
question, what is the basis for being able to provide such an identifier
and what is going to make the RP to feel warm and cozy about giving this
crucial part of _AUTHENTICATION_ to an external source? Why should an
identifier be better than an user name/password/email pair?
*

/ OpenID is decentralized.
/

Yes, the network is decentralized...

/No central authority must approve or register Relying Parties or
Identity Providers.
/

I have a problem with this one, since I believe, that there might be in
the end some kind of authority for compliance reasons perhaps, specially
on the IDP's...But this is perhaps for later after we agree, that there
must be a certain compliance by the IDP's.

/An End User can freely choose which Identity Provider to use.
/

Right!

/They can preserve their Identifier if they switch Identity Providers./

Not sure about that one....The whole URI or only the first part, aka
user name of an URI? What if it's occupied already at a different IDP?

/ While nothing in the protocol requires JavaScript or modern browsers,
the authentication scheme plays nicely with "AJAX"-style setups, so an
End User can prove their Identity to a Relying Party without having to
leave the page they are on.
/

Blah, blah...is this relevant at all? Is THIS important?/
/

/ OpenID Authentication uses only standard HTTP requests and responses,
so does not require any special capabilities of the User-Agent or other
software.
/

Well, now that's already not true! Accepted are http, https and
xri....Needs to be corrected...

/ The exchange of profile information, and other features not covered in
this specification, is addressed through additional Service Types built
on top of OpenID.
/

OK...I can live with that....So hopefully, this will be part of the
OpenID spec's too...

Now I took only the very first part of the draft spec's in order to
show, that there are things which might be corrected, defined and
included better...Specially the very first sentence requires a lot of
work....Suggestions?

Recordon, David wrote:
> So after typing that, please realize that is a one sentence definition
> of what it currently is.
>  
> --David
>

-- 
Regards
 
Signer:      Eddy Nigg, StartCom Ltd.
Phone:       +1.213.341.0390
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-security/attachments/20061026/62d5a8eb/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eddy_nigg.vcf
Type: text/x-vcard
Size: 636 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-security/attachments/20061026/62d5a8eb/attachment-0002.vcf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7282 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openid.net/pipermail/openid-security/attachments/20061026/62d5a8eb/attachment-0002.bin>