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

Seems to me you want to add the URI needed to initiate the WebID 
authentication protocol to HTTP requests. Why don't you just create a 
WebID-specific header (e.g. "webid") or a WebID-specific authorization 
scheme? Or is it imagined to initiate a OpenID process as well?

regards,
Torsten.

Am 19.07.2013 17:45, schrieb Kingsley Idehen:
> On 7/19/13 11:10 AM, Torsten Lodderstedt wrote:
>> Hi Kingsley,
>>
>> so your are essentially saying, the user agent (or a similar 
>> application) sets a URL, which the server uses in turn to obtain some 
>> values.
>
> To be precise, an end-user would (via UI/UX) have the *option* to 
> provide a URI that's added to the HTTP payload via an HTTP client 
> (e.g., a Browser or other User Agents).
>
>> These values are used to meet access control decisions. Did I get 
>> this right?
>
> The header values would then be incorporated into a mechanism for 
> protected resource access control and anything else that benefits from 
> verifiable identity.
>
>>
>> How does the server ensure the caller is the user represented by this 
>> URL?
>
> Through the logic of "shared secrets" and "mirrored claims" . This is 
> just about the ability to make an verify claims based on logic.
>
>> So for example, how would you prevent an attacker from sending your 
>> user id URL to the server (and in turn impersonating you on this server)?
>
> The server would verify identity based on logic. For instance, it can 
> verify that the user agent is being driven by an entity that has 
> access to:
>
> 1. private key which was used to make a signature -- stored locally 
> and accessed via native OS UI/UX controls (e.g., Keychain on Mac OS X)
> 2. certificate bearing claims that are mirrored in the document to 
> which the URI resolves
> 3. any other relationship that the data access policy deems worthy .
>
> Note, this already works. We are just seeking to simplify exploitation 
> entry points.
>
> Links:
>
> 1. http://bit.ly/UuWZSI -- various posts about this matter
> 2. http://bit.ly/UDlwc6 -- multi-identifier and multi-protocol based 
> identity verification.
>
> Kingsley
>>
>> Am 19.07.2013 um 15:42 schrieb Kingsley Idehen 
>> <kidehen@openlinksw.com <mailto:kidehen@openlinksw.com>>:
>>
>>> On 7/19/13 4:14 AM, Torsten Lodderstedt 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?
>>>
>>> It holds a URI that resolves to a document bearing content that 
>>> describes the URIs referent. For example, this document could be 
>>> comprised of a machine-readable entity->attribute->value  or 
>>> subject->predicate->object based relations.
>>>
>>> An end-user application (including browser extensions or plugins) 
>>> will set the value. A server will make use of these values e.g., 
>>> looking up the URIs to locate the description of the entity denoted 
>>> (named) by the URI. It can then use this description as the basis 
>>> for ACLs and sophisticated data access policies which are all driven 
>>> by logic.
>>>
>>>
>>> Kingsley
>>>>
>>>> Regards,
>>>> Torsten.
>>>>
>>>>
>>>>
>>>> Kingsley Idehen <kidehen@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
>>>>     Twitter/Identi.ca  <http://Identi.ca>  handle: @kidehen
>>>>     Google+ Profile:https://plus.google.com/112399767740508618350/about
>>>>     LinkedIn Profile:http://www.linkedin.com/in/kidehen
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> -- 
>>>
>>> Regards,
>>>
>>> Kingsley Idehen 
>>> Founder & CEO
>>> OpenLink Software
>>> Company Web:http://www.openlinksw.com
>>> Personal Weblog:http://www.openlinksw.com/blog/~kidehen
>>> Twitter/Identi.ca  <http://Identi.ca>  handle: @kidehen
>>> Google+ Profile:https://plus.google.com/112399767740508618350/about
>>> LinkedIn Profile:http://www.linkedin.com/in/kidehen
>>>
>>>
>>>
>>>
>
>
> -- 
>
> 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
>
>
>
>