On 19 Jul 2013, at 10:14, Torsten Lodderstedt <[email protected]> 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 [[ 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: [email protected] 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 I am not sure than any software makes much use of the From header. 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 ), 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 > > Regards, > Torsten. > > > > Kingsley Idehen <[email protected]> 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 > > Twitter/Identi.ca handle: @kidehen > Google+ Profile: > https://plus.google.com/112399767740508618350/about > > LinkedIn Profile: > http://www.linkedin.com/in/kidehen > > > > > > > _______________________________________________ > specs mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs Social Web Architect http://bblfish.net/ _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
