<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><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. These values are used to meet access control decisions. Did I get this right?</div><div><br></div><div>How does the server ensure the caller is the user represented by this URL? 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><div><br></div><div>Regards,</div><div>Torsten.</div><div><br>Am 19.07.2013 um 15:42 schrieb Kingsley Idehen <<a 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 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 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 class="moz-txt-link-freetext" href="http://www.openlinksw.com">http://www.openlinksw.com</a>
Personal Weblog: <a class="moz-txt-link-freetext" href="http://www.openlinksw.com/blog/~kidehen">http://www.openlinksw.com/blog/~kidehen</a>
Twitter/<a href="http://Identi.ca">Identi.ca</a> handle: @kidehen
Google+ Profile: <a class="moz-txt-link-freetext" href="https://plus.google.com/112399767740508618350/about">https://plus.google.com/112399767740508618350/about</a>
LinkedIn Profile: <a class="moz-txt-link-freetext" href="http://www.linkedin.com/in/kidehen">http://www.linkedin.com/in/kidehen</a>




</pre>
  

</div></blockquote></body></html>