[foaf-protocols] WebID spec: Subject Alternative Name extension
nathan at webr3.org
Fri Jul 16 17:36:06 CEST 2010
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).
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.
Hope that helps a little,
Seth Russell wrote:
> There are way too many if's in what you are proposing. Getting a usable
> email address from perhaps a foaf document, alone is a very iffy
> proposition. Then too, maybe its not a foaf document at the end of this
> quest. So what we have here provides nothing that we can use. It's like
> you sent up a rocket but didn't have the courage to put in the pay-load.
> So if a customer chooses their certificate from their browser and sends
> it back to the merchant, what are they saying to the merchant ...
> precisely nothing. It sure seems to me that if you put your email in your
> certificate and send the certificate to a merchant, then you certainly want
> that merchant to easily be able to get that email and use it.
> Seth Russell
> Alpha testing: tagtalking.net
> Facebook ing: facebook.com/russell.seth
> Twitter ing: twitter.com/SethRussell
> Blogging: fastblogit.com/seth/
> Catalog selling: www.speaktomecatalog.com
> Google profile: google.com/profiles/russell.seth
> On Fri, Jul 16, 2010 at 8:01 AM, Bruno Harbulot <
> Bruno.Harbulot at manchester.ac.uk> wrote:
>> Sure, all I'm saying is that it's already within the scope of FOAF
>> As such, I'd treat it as outside the scope of this specification.
>> When merchants get the WebID Profile document, as they should to get the
>> information about the user, they'll be able to see if there is a foaf:mbox
>> with an e-mail address. If there isn't, they'll have to ask the user as they
>> do now.
>> Best wishes,
>> On 16/07/10 15:49, Seth Russell wrote:
>>> Well i'm not requesting that the specification "mandate" the disclosure
>>> of an email address. I am just requesting that if the customer wants
>>> to give the merchant their email address, then the specification
>>> standardize how that is done so the merchant can reliably get it.
>>> A little background is needed here. We always have the chicken or the
>>> egg problem to get a protocol flourishing: no merchants will bother to
>>> implement, if there are no customers out there to use it, and no
>>> customers will bother to get certificates if there are not places that
>>> use them. By kicking this one down the road to some geeky foaf
>>> document will make the chicken and egg paramount. Look there are
>>> zillions of merchants and web sites out there who just need identity
>>> and email to be able to function ... to do what they are setup to do.
>>> You can give all of those web sites a very good reason to implement your
>>> protocol if you give them the one thing that dearly need, the ability to
>>> communicate back to their customers.
>>> 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 <
>>> Google profile: google.com/profiles/russell.seth
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
More information about the foaf-protocols