Re: [community] from W3C….Fwd: Proposal: "User" header field

Sat Jul 27 05:58:02 UTC 2013

On 20 July 2013 17:57, Kingsley Idehen <kidehen at openlinksw.com> wrote:

> On 7/20/13 6:41 AM, Henry Story wrote:
>
>> On 19 Jul 2013, at 10:14, Torsten Lodderstedt <torsten at lodderstedt.net>
>> wrote:
>>
>>  Hi,
>>>
>>> could you please shed some light on the use case for the User field?
>>> What entity sets the value, what entitity uses it for what purpose?
>>>
>> The simplest answer would have to be: the use case is the same as
>> whatever the use case was for the
>> 'From' header. This is specified here:
>>
>> http://www.w3.org/Protocols/**rfc2616/rfc2616-sec14.html#**sec14.22<http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.22>
>>
>> [[
>> The From request-header field, if given, SHOULD contain an Internet
>> e-mail address for the human user who controls the requesting user agent.
>> The address SHOULD be machine-usable, as defined by "mailbox" in RFC 822
>> [9] as updated by RFC 1123 [8]:
>>
>>         From   = "From" ":" mailbox
>>
>> An example is:
>>
>>         From: webmaster at w3.org
>>
>> This header field MAY be used for logging purposes and as a means for
>> identifying the source of invalid or unwanted requests. It SHOULD NOT be
>> used as an insecure form of access protection. The interpretation of this
>> field is that the request is being performed on behalf of the person given,
>> who accepts responsibility for the method performed. In particular, robot
>> agents SHOULD include this header so that the person responsible for
>> running the robot can be contacted if problems occur on the receiving end.
>> ]]
>>
>> So if having an e-mail address is ok in the standard, then presumably
>> having a WebID is also ok.
>> WebID is defined here: https://dvcs.w3.org/hg/WebID/**
>> raw-file/tip/spec/identity-**respec.html<https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html>
>>
>> I am not sure than any software makes much use of the From header.
>>
>
> That's the most amazing thing of all, the header isn't used. Nobody has
> been able to provide any data to back its use in the field.
>
>
>
>> We do have a good use case for an "On-Behalf-Of" header which would allow
>> robots specify that
>> they are making their requests On-Behalf of a user. The robot would
>> authentication using WebID
>> over TLS ( https://dvcs.w3.org/hg/WebID/**raw-file/tip/spec/tls-respec.**
>> html <https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/tls-respec.html> ),
>> and send an HTTP request
>>
>> GET /somedoc HTTP/1.1
>> On-Behalf-Of: http://jane.example/u/card#me
>> ...
>>
>> and the WeBID profile of the user specified in the On-Behalf-Of field
>> could then be
>> fetched by the server to check that it contained a relation say
>>
>>    <#me> :secretary </u/robot#h2d2> .
>>
>> This would then tell the server that the robot making the request could
>> do so on behalf  of the user. So if an access control rule for the
>> requested
>> resource allowed an agent that had made the request On-Behalf-Of a user
>> to do so,
>> and this could be verified, then the server could server the resource.
>>
>> As it happens the From: field covers the On-Behalf-Of use case. It says
>> so clearly
>> in the spec:
>> "The interpretation of this field is that the request is being performed
>> on behalf of the person given,"
>>
>> Furthermore the HTTP1.1 RFC only restricts the identity used in an e-mail
>> to a SHOULD.
>> Therefore it should be ok to use the FROM header, as specified above,
>> given that
>> I don't think the From header is ever used. Otherwise creating a new
>> On-Behalf-Of field
>> will be the other option.
>>
>> Henry
>>
>
> That will work too. We just need a header of some sort.  Right now though,
> "User: " is being used, so we are going to support that as a starting point.
>

Hi All

Thanks for all the feedback on this.  Having followed many identity systems
from the start, it's great to see different communities in conversation.
I'd like to summarize some of the points put forward in this thread:

1. *Present a use case*.  I think the motivation of this header is going to
be easier to understand if one or more use cases can be documented.  I
think it would make some sense to prepare some notes and maybe mockups of
how this header could be leveraged.  We have a wiki in the community group
so this could be a good place to start.

2. *The user experience is important*.  It would be beneficial to describe
a use might be able to set this header, either manually by typing/clicking
or in an automated fashion.  I think it would be possible to draw up some
wireframes, or perhaps mock up some prototypes, in order to visualize the
workflow of creating this header, and being able to opt in to send it to a
server.

3. *Security is important*.  It is important to consider security
implications of this header and make sure that it is well documented in the
description.  Bear in mind that there is an element of human error where
implementers may assume that the header set has also been authenticated,
which may not be the case.

4. *Naming considerations*.  There would appear to be no existing mechanism
to reuse for this header.  The "From" header despite using the term SHOULD
for a mailbox, is strictly defined in the ABNF to exclude other types of
identifier.  We've been asked to think of another name.  On-behalf-of, also
seems to be an imperfect match, and OAuth tokens do something slightly
different.  User and UserID have been suggested, and since User is already
used in data.fm seems a good fit.  It seems sensible to flesh out the use
case for tentatively using "User" as a working code name.

So, at this point, it sounds like we have a bit of work to do, in fleshing
out the documentation.  Please let me know if you have any further
questions or concerns.

>
> Kingsley
>
>
>>  Regards,
>>> Torsten.
>>>
>>>
>>>
>>> Kingsley Idehen <kidehen at openlinksw.com> schrieb:
>>> On 7/18/13 1:38 PM, Torsten Lodderstedt wrote:
>>>
>>>> I fully agree with George und would like to add: why don't you just use
>>>> the authorization header to send identity data/credentials/tokens to the
>>>> server in order to allow for access control?
>>>>
>>> This is already possible. The requirement here stems from the fact that
>>> "From:" is bound specifically to mailto: scheme URIs (Uniform Resource
>>> Identifiers). We are looking to "User:" to be the superClass of "From:"
>>> which is basically URI scheme agnostic. That's it.
>>>
>>> [SNIP]
>>> --
>>>
>>> Regards,
>>>
>>> Kingsley Idehen
>>> Founder & CEO
>>> OpenLink Software
>>> Company Web:
>>> http://www.openlinksw.com
>>>
>>> Personal Weblog:
>>> http://www.openlinksw.com/**blog/~kidehen<http://www.openlinksw.com/blog/~kidehen>
>>>
>>> Twitter/Identi.ca handle: @kidehen
>>> Google+ Profile:
>>> https://plus.google.com/**112399767740508618350/about<https://plus.google.com/112399767740508618350/about>
>>>
>>> LinkedIn Profile:
>>> http://www.linkedin.com/in/**kidehen<http://www.linkedin.com/in/kidehen>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ______________________________**_________________
>>> specs mailing list
>>> specs at lists.openid.net
>>> http://lists.openid.net/**mailman/listinfo/openid-specs<http://lists.openid.net/mailman/listinfo/openid-specs>
>>>
>> Social Web Architect
>> http://bblfish.net/
>>
>>
>>
>>
>
> --
>
> Regards,
>
> Kingsley Idehen
> Founder & CEO
> OpenLink Software
> Company Web: http://www.openlinksw.com
> Personal Weblog: http://www.openlinksw.com/**blog/~kidehen<http://www.openlinksw.com/blog/~kidehen>
> Twitter/Identi.ca handle: @kidehen
> Google+ Profile: https://plus.google.com/**112399767740508618350/about<https://plus.google.com/112399767740508618350/about>
> LinkedIn Profile: http://www.linkedin.com/in/**kidehen<http://www.linkedin.com/in/kidehen>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20130727/23b2cf3e/attachment.html>