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

Nathan nathan at webr3.org
Fri Jul 16 17:36:06 CEST 2010


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).

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,

Nathan

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
>>  http://xmlns.com/foaf/spec/#term_mbox
>>
>> 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,
>>
>> Bruno.
>>
>>
>>
>> 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 <
>>> http://www.speaktomecatalog.com>
>>>
>>> Google profile: google.com/profiles/russell.seth
>>> <http://google.com/profiles/russell.seth>
>>>
>>>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols



More information about the foaf-protocols mailing list