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

[Seth Russell]

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

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

I disagree.  If the merchant asks you to identify yourself and provide a way
to communicate back with you.   Then  if you choose  a certificate of your
own volition which contains the message "here is the email address to
contact me", then you have already answered the question : "what email
address should be used to contact you".

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



> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20100716/63926165/attachment-0001.htm