<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
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?<br>
<br>
regards,<br>
Torsten.<br>
<br>
<div class="moz-cite-prefix">Am 19.07.2013 17:45, schrieb Kingsley
Idehen:<br>
</div>
<blockquote cite="mid:51E95F17.5000203@openlinksw.com" type="cite">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<div class="moz-cite-prefix">On 7/19/13 11:10 AM, Torsten
Lodderstedt wrote:<br>
</div>
<blockquote
cite="mid:D671F542-FF0B-4FC9-99AC-37F09E0A01D1@lodderstedt.net"
type="cite">
<div>Hi Kingsley,</div>
<div><br>
</div>
<div>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. </div>
</blockquote>
<br>
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). <br>
<br>
<blockquote
cite="mid:D671F542-FF0B-4FC9-99AC-37F09E0A01D1@lodderstedt.net"
type="cite">
<div>These values are used to meet access control decisions. Did
I get this right?</div>
</blockquote>
<br>
The header values would then be incorporated into a mechanism for
protected resource access control and anything else that benefits
from verifiable identity. <br>
<br>
<blockquote
cite="mid:D671F542-FF0B-4FC9-99AC-37F09E0A01D1@lodderstedt.net"
type="cite">
<div><br>
</div>
<div>How does the server ensure the caller is the user
represented by this URL? </div>
</blockquote>
<br>
Through the logic of "shared secrets" and "mirrored claims" . This
is just about the ability to make an verify claims based on logic.
<br>
<br>
<blockquote
cite="mid:D671F542-FF0B-4FC9-99AC-37F09E0A01D1@lodderstedt.net"
type="cite">
<div>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)?</div>
</blockquote>
<br>
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:<br>
<br>
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)<br>
2. certificate bearing claims that are mirrored in the document to
which the URI resolves<br>
3. any other relationship that the data access policy deems worthy
.<br>
<br>
Note, this already works. We are just seeking to simplify
exploitation entry points. <br>
<br>
Links:<br>
<br>
1. <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://bit.ly/UuWZSI">http://bit.ly/UuWZSI</a> -- various
posts about this matter<br>
2. <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://bit.ly/UDlwc6">http://bit.ly/UDlwc6</a> --
multi-identifier and multi-protocol based identity verification.<br>
<br>
Kingsley
<blockquote
cite="mid:D671F542-FF0B-4FC9-99AC-37F09E0A01D1@lodderstedt.net"
type="cite">
<div><br>
Am 19.07.2013 um 15:42 schrieb Kingsley Idehen <<a
moz-do-not-send="true" href="mailto:kidehen@openlinksw.com">kidehen@openlinksw.com</a>>:<br>
<br>
</div>
<blockquote type="cite">
<div>
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 7/19/13 4:14 AM, Torsten
Lodderstedt wrote:<br>
</div>
<blockquote
cite="mid:58653cc8-cb68-4d29-9460-8c3d9c7f71d4@email.android.com"
type="cite">
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
Hi,<br>
<br>
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? <br>
</blockquote>
<br>
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. <br>
<br>
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. <br>
<br>
<br>
Kingsley <br>
<blockquote
cite="mid:58653cc8-cb68-4d29-9460-8c3d9c7f71d4@email.android.com"
type="cite"> <br>
Regards,<br>
Torsten.<br>
<br>
<div class="gmail_quote"><br>
<br>
Kingsley Idehen <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:kidehen@openlinksw.com"><kidehen@openlinksw.com></a>
schrieb:
<blockquote class="gmail_quote" style="margin: 0pt 0pt
0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div class="moz-cite-prefix">On 7/18/13 1:38 PM,
Torsten Lodderstedt wrote:<br>
</div>
<blockquote
cite="mid:79cf3a27-c0d1-43e1-b1e6-6442e1d2c13c@email.android.com"
type="cite"> 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?<br>
</blockquote>
<br>
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. <br>
<br>
[SNIP]<br>
<pre class="moz-signature" cols="72">--
Regards,
Kingsley Idehen
Founder & CEO
OpenLink Software
Company Web: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.openlinksw.com">http://www.openlinksw.com</a>
Personal Weblog: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.openlinksw.com/blog/%7Ekidehen">http://www.openlinksw.com/blog/~kidehen</a>
Twitter/<a moz-do-not-send="true" href="http://Identi.ca">Identi.ca</a> handle: @kidehen
Google+ Profile: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://plus.google.com/112399767740508618350/about">https://plus.google.com/112399767740508618350/about</a>
LinkedIn Profile: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.linkedin.com/in/kidehen">http://www.linkedin.com/in/kidehen</a>
</pre>
</blockquote>
</div>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Regards,
Kingsley Idehen
Founder & CEO
OpenLink Software
Company Web: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.openlinksw.com">http://www.openlinksw.com</a>
Personal Weblog: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.openlinksw.com/blog/%7Ekidehen">http://www.openlinksw.com/blog/~kidehen</a>
Twitter/<a moz-do-not-send="true" href="http://Identi.ca">Identi.ca</a> handle: @kidehen
Google+ Profile: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://plus.google.com/112399767740508618350/about">https://plus.google.com/112399767740508618350/about</a>
LinkedIn Profile: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.linkedin.com/in/kidehen">http://www.linkedin.com/in/kidehen</a>
</pre>
</div>
</blockquote>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Regards,
Kingsley Idehen
Founder & CEO
OpenLink Software
Company Web: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.openlinksw.com">http://www.openlinksw.com</a>
Personal Weblog: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.openlinksw.com/blog/%7Ekidehen">http://www.openlinksw.com/blog/~kidehen</a>
Twitter/Identi.ca handle: @kidehen
Google+ Profile: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://plus.google.com/112399767740508618350/about">https://plus.google.com/112399767740508618350/about</a>
LinkedIn Profile: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.linkedin.com/in/kidehen">http://www.linkedin.com/in/kidehen</a>
</pre>
</blockquote>
<br>
</body>
</html>