[foaf-protocols] WebID spec: Subject Alternative Name extension

Seth Russell russell.seth at gmail.com
Fri Jul 16 22:37:19 CEST 2010


On Fri, Jul 16, 2010 at 8:36 AM, Nathan <nathan at webr3.org> wrote:

> Hi Seth,
>
> I have to agree in principal, possibly we're getting to something outside
> of the scope of WebID though. AFAICT here's how it is:
>
> If you are requesting a certificate from somebody then that is to verify
> who they are, to do this you must dereference and understand what's on the
> other side before allowing the user to continue, at this point you know for
> sure you can understand the profile returned (in a format way, not ontology
> way) from there you either find 1-many email addresses for that user or not,
> if many you ask them which one, if one you ask them to confirm that's the
> one they want, if none you ask them for an email.
>
> You could just pull the email address from the certificate (if one exists)
> but you'd still be in the same scenario of needing a manual confirmation
> that is in fact the email address the client wants you to use to contact
> them.
>
> Thus, it's outside the scope of the protocol and each application is free
> to choose how it get's an email address from a person (assuming there is a
> user and not an application/agent).
>

Is making a specification that will actually give thousands  of websites
all they need to "get rid of the username and password  tedium" also outside
the scope of this standard?

One could standardize something here - personally my vote would be to go to
> the semantic web and linked data groups and define a single property which
> relates to an email address, and which all email related properties
> subclass, I think it's important enough to have a single upper property for
> it (like rdfs:label is to names/labels).
>
> Certificate wise, email: is already part of the subjectAltName extension,
> and if you find one in the cert you can use it in your application as you
> decide - I'd still recommend always verifying with the person that's the one
> they want to use though.
>

Hmm ... strange i can't find that in the X 509 ITU recommendation  which i
take is the document at http://bit.ly/d4wfXB

That document does say:  "These certificate and CRL extensions support
alternative names, of various
name forms, for a certificate subject, a certificate issuer, or a CRL
issuer. These extensions can also
convey additional attribute information about the certificate subject, to
assist a certificate user in being
confident that the certificate subject is a particular person or entity."
In other words it is totally up to the implementer how they put in the meail
address.   Some may go email: x at y.com  others go mailto: x at y.com  ... who
knows programmers will do unless the standard recommends something.

Now there is an example in the doucment at
http://www.openssl.org/docs/apps/x509v3_config.html#Subject_Alternative_Name_
But an example is not what we need.    We need the standard to something
like:

      If the client provides their email address in the certificate
      for the purposes they are submitting the certificate to the server,
      then it must be provided in exactly this format.

Again that can be generalized to specify all manner of future communication
from the server to the client ... including ping.   This should not forstall
dereferecing a foaf file to get that same information.  It just provides an
alternative more reliable, less iffy path to the essential information.

Let's face it, we all want this thing to take off and be used.   If you
don't make it useful for websites to implement, then they simply won't
implement ... sans those websites implementations this specification is
useless.   We need to motivate those implementations.   To do that , give
them what they need to make it work.  If you just give them futures and
vaugenessess which cannot be relied upon, don't work now except for a
handful of geeks, this specification will be doa.   Thing is, if you give us
what we need now, then you have your foot in the door, and all that really
interesting linkeddata stuff can start to happen.

Seth Russell
Alpha testing: tagtalking.net <http://tagtalking.net>
Facebook ing: facebook.com/russell.seth <http://facebook.com/russell.seth
Twitter ing: twitter.com/SethRussell <http://twitter.com/SethRussell>
Blogging: fastblogit.com/seth/ <http://fastblogit.com/seth/>
Catalog selling: www.speaktomecatalog.com <
http://www.speaktomecatalog.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20100716/82fc6160/attachment.htm 


More information about the foaf-protocols mailing list