Re: [apps-discuss] webfinger privacy question/suggestion

[William Mills <[e-mail]>]

>The best services let users choose what profile data to share with
>whom (show my phone number only to friends and family) and most just
>let the user choose whether to share the data at all or not.


Yes, allowing the user to control what information is shared is key.  Note that we have multiple classes of informaiton, so that personal information like a vcard will be handled differently than service information like what OAuth endpoint is used ot authenticate the user.




>________________________________
> From: Evan Prodromou <[e-mail]>
>To: IETF Apps Discuss <[e-mail]> 
>Sent: Wednesday, October 31, 2012 12:25 PM
>Subject: Re: [apps-discuss] webfinger privacy question/suggestion
> 
>
>On 12-10-31 12:32 PM, James M Snell wrote:
>
>What is a problem, however, is that you've mentioned a few times that TLS could provide the necessary privacy control but there does not appear to be any mention at all of TLS within the specification document. It really should be called out as a specific recommendation in the text. 
>I also note that while you do cover some of the privacy issues in the security considerations, one point could stand to be made clearer: WebFinger should only be used to expose information the subject has explicitly opted in to be shared. Or put another way, WebFinger MUST NOT be used to provide information to any party the subject has not explicitly authorized. This is loosely implied by the current text but, unless I missed it, you never just come out and say it.
That seems exceptionally strong. It also doesn't reflect current practice for Web services which often provide profile pages or other human-readable endpoints that include by default at least some of the profile data provided by the user.
>
>The best services let users choose what profile data to share with
    whom (show my phone number only to friends and family) and most just
    let the user choose whether to share the data at all or not.
>
>For machine-readable endpoints, I think it's untenable. I can say
    right now that there's no way I'll ever create user interfaces to ask that a user explicitly opt in to e.g. publishing their Salmon protocol endpoint.
>
>Maybe a better way to say it is: the implementor SHOULD let users
    opt out of sharing personally-identifying information, or data that
    correlates to other accounts or identities, and SHOULD inform users
    that the data is being shared in e.g. a terms of service agreement.
>
>2. A cryptographic hashed identifier could help prevent correlation style breaches in privacy if the hash is generated based on a shared secret key tied to the requesters authenticated identity. That is, if a WebFinger server requires authentication to request data, the requester can generate an hmac, for instance, using a shared secret key and specify that within the URI request. Used in combination with TLS, for example, this would provide a reasonable assurance of privacy between the requester and the service provider, keeping prying eyes in the middle from knowing whose information is being requested. Again, it is possible to do with currently without any changes to the WF protocol as defined so no normative changes would be necessary, but it might be worthwhile to draw out as an informative example.
James, could you give an explicit example of the problem and what the solution is? I see at least two or three things here that you're laying out.
>
>-Evan
>
>-- 
Evan Prodromou, CEO and Founder, StatusNet Inc.
1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7
E: [e-mail] P: [phone]
>_______________________________________________
>apps-discuss mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/apps-discuss
>
>
>