Re: [Auth]Re: What I percieve is wrong with IDsec (was IDsec specification draft)

[Rhys Weatherley]

Mike Warren wrote:

> If you tell me you're ``Rhys Weatherley'', that is probably perfectly
> fine for an email conversation about a project (and I don't need IDsec
> to tell me this) but what about when you're selling me a car and tell
> me via the Internet that you're ``Rhys Weatherley''. In that case, I
> want proof. I want some mutually trustworthy third party to say,
> ``yes, Mike, he's really called Rhys Weatherley''.

If I have a digital certificate signed by a trusted third party,
then I can provide you with my certificate and a signed
transaction.  You can verify this transaction without knowing
anything else about me.

Remote profile providers aren't necessary for this scenario.
The certificate, once signed and issued, can be stored in
the local profile.  You can always verify it by checking the
certificate against the trusted third party's public key.

If certificates are too much bother, then it is necessary for
me to login to the trusted third party, get a cookie for the
role, and then present it to you.  You verify this cookie
and then you can trust me.  As long as the cookie
protocol is secure, you don't need to know anything
else about me.

There are two sides to "identity": information and roles.  The
scenario you describe needs a role, but it doesn't need any
information.  If I want to provide extra information to you
from my local profile, I can, but it is my choice.

The danger with systems like Passport is that they mix up
information and roles, which makes it highly likely that the
information will be leaked whenever the user engages in
a role.  One might argue that this mix-up is deliberate.
Roles are boring.  Information can be re-sold for profit.

Cheers,

Rhys.