<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
So from an authentication/validation perspective, it appears that
the data in the HTTP request must be tied in some secure way to the
user identified in the hint. Otherwise, it's easy for me to
impersonate someone by just sending a different hint.<br>
<br>
From an JOSE perspective, it could be the URL to a JWKS that
contains my individual public key data.<br>
<br>
I am a little worried about global correlation with a header like
this.<br>
<br>
Thanks for the explanation.<br>
<br>
I do agree with Torsten that using the Authorization header via
OAuth2 Bearer seems like simpler solution. This can obviate the need
for the back-channel request for authorization.<br>
<br>
Thanks,<br>
George<br>
<br>
<div class="moz-cite-prefix">On 7/18/13 1:54 PM, Melvin Carvalho
wrote:<br>
</div>
<blockquote
cite="mid:CAKaEYh+8TfCdESFvSQr45NcL0uwy-=Q2WUTZUMJg0BmR119YQg@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra">
<div class="gmail_quote">On 18 July 2013 18:59, George
Fletcher <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:gffletch@aol.com" target="_blank">gffletch@aol.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> <font
face="Helvetica, Arial, sans-serif">I'm a little
confused... first the spec says<br>
</font>
<div class="im">
<blockquote><font face="Helvetica, Arial, sans-serif">The
current text includes: "It SHOULD NOT be used as
an insecure form of access protection." -- This
is the same as the "From" header (which may
contain an email address). Do you think stronger
wording is required.<br>
</font></blockquote>
</div>
<font face="Helvetica, Arial, sans-serif">and then you
follow that up with<br>
</font>
<div class="im">
<blockquote><font face="Helvetica, Arial, sans-serif">In
particular, one thing we are working on in the
Read Write Web Community Group is fine grained
access control for writing or appending a file.
It's helpful to know who is trying to make a
change before returning e.g. SUCCESS or FORBIDDEN
response codes.<br>
</font></blockquote>
</div>
<font face="Helvetica, Arial, sans-serif">Since there is
no authentication or proof associated with the 'User'
header, how can you use it for fine grained access
control? Is the expectation that the value is an
untrusted identification of the user that can be used
to optimize certain use cases? If so, I'm not sure
which use cases it helps?<br>
</font></div>
</blockquote>
<div><br>
</div>
<div>That you are able to identify yourself does not imply
that verifying that identity is impossible. The auth part
is simply not in scope, the same as with the "From"
header.<br>
<br>
</div>
<div>In practice what we tend to do is dereference the URL
and look for a public key, then use PKI for verification,
but that's only one way to do auth. There are many ways
to do so, as John pointed out, you could delegate to your
OpenID provider too, so you get the best of all worlds.<br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><font
face="Helvetica, Arial, sans-serif"> <br>
Thanks,<br>
George<br>
</font>
<div>
<div class="h5"><br>
<div>On 7/18/13 12:49 PM, Melvin Carvalho wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On 18 July 2013
01:54, John Kemp <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:john@jkemp.net"
target="_blank">john@jkemp.net</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"> The
problem, in general, with putting
identifiers in HTTP requests is that they
get mistaken for being real things. User
is no worse (or better) than User-Agent.
Remember all of the mess about how
websites would attempt to render sites to
clients based on the contents of the
User-Agent header, and how long it's taken
for something better to appear for that
task?<br>
</blockquote>
<div><br>
</div>
<div>Yes, I agree that User-Agent can be
slightly problematic. Some spiders such
as googlebot actually put their URL in the
User-Agent header, as a semi-colon
separated list, which is not ideal. The
user and the user-agent are different
concepts. The proposed header would be a
simpler solution, imho. <br>
</div>
<div> </div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"> <br>
'Just a hint' doesn't tell anyone what
this is really going to be used for. Are
there use-cases written down, in addition
to a syntax?<br>
</blockquote>
<div><br>
</div>
<div>The current text includes: "It SHOULD
NOT be used as an insecure form of access
protection." -- This is the same as the
"From" header (which may contain an email
address). Do you think stronger wording
is required.<br>
<br>
</div>
<div>The use case is the same as "From" in
fact, my ideal would have been just to
loosen the scope of "From" but there was
pushback from the IETF on this, with the
suggestion to think of another header
name.<br>
<br>
</div>
<div>In particular, one thing we are working
on in the Read Write Web Community Group
is fine grained access control for writing
or appending a file. It's helpful to know
who is trying to make a change before
returning e.g. SUCCESS or FORBIDDEN
response codes.<br>
</div>
<div> </div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"> <br>
On a more specific level, this looks like
"On-behalf-of" - a more indicative name
than "user" for the seemingly potential
usage (this request is performed on behalf
of the user X)?<br>
</blockquote>
<div> <br>
</div>
<div>I'd be very happy to reuse something
existing, so long as it allowed URLs and
email address too. If I'm correct,
On-behalf-of is email specific?<br>
</div>
<div> </div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"> <br>
I'm not sure why OpenIDs couldn't appear
in this header, FWIW. The recipient could
run OpenID protocol with the client,
regarding the identifier sent in the
header. That would allow "verification" of
the OpenID to occur, wouldn't it?<br>
</blockquote>
<div><br>
</div>
<div>Well I hadnt thought of that, but yes
that could work quite well! One of the
perceived issues with OpenID as a URL
(dating back as far as Yadis) was that the
UX for typing in an HTTP URL lead to a
loss of conversions. If this could be
done by the software and may save some
typing, especially on mobile devices. The
same technique could be used with PKI if
the URL contained a public key and the
(rich) client could store the private
key. I think that will become a more
valuable use case next year when crypto on
the browser becomes a REC<br>
</div>
<div> </div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"> <span><font
color="#888888"><br>
John<br>
</font></span>
<div>
<div><br>
On Jul 17, 2013, at 7:41 PM, Melvin
Carvalho <<a moz-do-not-send="true"
href="mailto:melvincarvalho@gmail.com" target="_blank">melvincarvalho@gmail.com</a>>
wrote:<br>
<br>
><br>
><br>
><br>
> On 18 July 2013 01:06, Nat
Sakimura <<a moz-do-not-send="true"
href="mailto:sakimura@gmail.com"
target="_blank">sakimura@gmail.com</a>>
wrote:<br>
> Hi.<br>
><br>
> I am forwarding the mail in the
identity commons list.<br>
><br>
> Apparently, there is an
initiative at W3C proposing a new
"identity" header, which I believe is
actually harmful for the general
public. Simple web sites are going to
take it as authenticated identity and
thus will cause identity theft of
their users.<br>
><br>
> Their proposal is to include<br>
><br>
> User: <a
moz-do-not-send="true"
href="http://this.is.the/user/identifier"
target="_blank">http://this.is.the/user/identifier</a><br>
><br>
> in the HTTP header.<br>
><br>
> Could those of you active in W3C
reach out to them?<br>
><br>
> As I have written below, if it
were to just include the IdP address
as a hint, I am kind of fine.<br>
><br>
> Thanks for sharing this. Since
this was my proposal, I hope I can
shed a bit of light light.<br>
><br>
> Firstly, it's not the W3C, simply
a group of people brainstorming in the
a W3C hosted forum (aka community
groups). The proposal has no official
standing, but if there are no
objections, the idea is to try and
push the idea upstream.<br>
><br>
> Yes, the idea is that it is just
a hint. Note the text:<br>
><br>
> "The client SHOULD NOT send the
User header field without the user's
approval, as it might conflict with
the user's privacy interests or their
site's security policy. It is strongly
recommended that the user be able to
disable, enable, and modify the value
of this field at any time prior to a
request."<br>
><br>
> We asked the IETF if we could use
the "From" header for this, but the
feedback is that "From" is restricted
to email, and this would be difficult
to change. The suggestion was to come
up with a new header. Very happy to
have feedback, I've followed IIW work
for many years.<br>
><br>
><br>
> Best,<br>
><br>
> Nat<br>
><br>
> ---------- Forwarded message
----------<br>
> From: Kaliya "Identity Woman"
<<a moz-do-not-send="true"
href="mailto:kaliya-lists@identitywoman.net"
target="_blank">kaliya-lists@identitywoman.net</a>><br>
> Date: 2013/7/18<br>
> Subject: Re: [community] from
W3C….Fwd: Proposal: "User" header
field<br>
> To: Nat Sakimura <<a
moz-do-not-send="true"
href="mailto:sakimura@gmail.com"
target="_blank">sakimura@gmail.com</a>><br>
> Cc: "<a moz-do-not-send="true"
href="mailto:community@lists.idcommons.net"
target="_blank">community@lists.idcommons.net</a>"
<<a moz-do-not-send="true"
href="mailto:community@lists.idcommons.net"
target="_blank">community@lists.idcommons.net</a>><br>
><br>
><br>
> Yes Nat, Thats sort of what I
got from reading it.<br>
><br>
> Who among us is very active in
the W3C world?<br>
><br>
> If no one should we be figuring
out who should be?<br>
><br>
> Should we write them a letter
asking them to send "identitish"
proposals to IIW? or other forums for
good input?<br>
><br>
> Maybe we should write something
that is like understanding identity
basics for technical specification
folks across a range of standards
bodies?<br>
><br>
> - Kaliya<br>
><br>
> On Jul 17, 2013, at 3:32 AM, Nat
Sakimura wrote:<br>
><br>
>> Whoa, what's that?!<br>
>><br>
>> That's not only useless but
actually harmful.<br>
>><br>
>> I can kind of see some
utility in sending the IdP address,
but not the user.<br>
>><br>
>> =nat via iPhone<br>
>><br>
>> On Jul 16, 2013, at 7:39,
"Kaliya \"Identity Woman\"" <<a
moz-do-not-send="true"
href="mailto:kaliya-lists@identitywoman.net"
target="_blank">kaliya-lists@identitywoman.net</a>>
wrote:<br>
>><br>
>>> Hi folks,<br>
>>> Apparently the W3C wants
to send "user" names along in HTTP
headers.<br>
>>> I thought some folks
who know about identity and how it
does/could/should work might be up for
chiming in over there.<br>
>>> It seems like
Authentication of identity might be a
good thing rather then just assertion.<br>
>>> - Kaliya<br>
>>><br>
>>><br>
>>> Begin forwarded message:<br>
>>><br>
>>>> From: Christine<br>
>>><br>
>>>> As you know, I'm a
big proponent of open standards. For
this reason I monitor many groups. You
might be interested in the W3C Read
Write Web community group: <a
moz-do-not-send="true"
href="http://www.w3.org/community/rww/"
target="_blank">http://www.w3.org/community/rww/</a><br>
>>>><br>
>>>> I sent you a message
a few weeks ago about Tabulator.<br>
>>>><br>
>>>> See below messages
about User header field. If you are
not already a member, I recommend you
join and contribute!<br>
>>>><br>
>>>> Christine<br>
>>>><br>
>>>><br>
>>>> -------- Original
Message --------<br>
>>>> Subject: Re:
Proposal: "User" header field<br>
>>>> Resent-Date:
Sat, 13 Jul 2013 16:19:02 +0000<br>
>>>> Resent-From: <a
moz-do-not-send="true"
href="mailto:public-rww@w3.org"
target="_blank">public-rww@w3.org</a><br>
>>>> Date: Sat, 13
Jul 2013 12:08:37 -0400<br>
>>>> From: Joe <<a
moz-do-not-send="true"
href="mailto:presbrey@gmail.com"
target="_blank">presbrey@gmail.com</a>><br>
>>>> To: Melvin
Carvalho <<a moz-do-not-send="true"
href="mailto:melvincarvalho@gmail.com" target="_blank">melvincarvalho@gmail.com</a>><br>
>>>> CC: public-rww
<<a moz-do-not-send="true"
href="mailto:public-rww@w3.org"
target="_blank">public-rww@w3.org</a>><br>
>>>><br>
>>>> Great job Melvin!<br>
>>>><br>
>>>> Data.fm sends the
User header already :)<br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> On Jul 13, 2013, at
10:55 AM, Melvin Carvalho <<a
moz-do-not-send="true"
href="mailto:melvincarvalho@gmail.com"
target="_blank">melvincarvalho@gmail.com</a>>
wrote:<br>
>>>><br>
>>>>> I would be nice
to be able to identify a user in HTTP,
especially with read/write protocols
and access control, it can be
important to know who is trying to
change something.<br>
>>>>><br>
>>>>> There has been
some discussion on whether the "From"
header can be used to identify a user
in HTTP, and my from most people is
that this would be a good candidate to
send a user, but for historical
reasons it's limited to email, and
changing this would perhaps get some
pushback from the IETF.<br>
>>>>><br>
>>>>> The suggestion
has been to choose another header, so
I thought that "User" might be a good
candidate, since we have User Agent
arleady.<br>
>>>>><br>
>>>>> Here's the
proposed text:<br>
>>>>><br>
>>>>> [[<br>
>>>>> User<br>
>>>>><br>
>>>>> The User
request-header field, if given, SHOULD
contain an identifier for the human
user who controls the requesting user
agent. The address SHOULD be
machine-usable, as defined by the "URI
General Syntax" RFC 3986<br>
>>>>> User =
"User" ":" URI<br>
>>>>><br>
>>>>> An example is:<br>
>>>>><br>
>>>>> User: <a
moz-do-not-send="true"
href="http://www.w3.org/People/Berners-Lee/card#i"
target="_blank">http://www.w3.org/People/Berners-Lee/card#i</a><br>
>>>>> 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.<br>
>>>>><br>
>>>>><br>
>>>>> The client SHOULD
NOT send the User header field without
the user's approval, as it might
conflict with the user's privacy
interests or their site's security
policy. It is strongly recommended
that the user be able to disable,
enable, and modify the value of this
field at any time prior to a request.<br>
>>>>><br>
>>>>> ]]<br>
>>>>><br>
>>>>> Feedback welcome!<br>
>>>>><br>
>>>><br>
>>>><br>
>>><br>
>>><br>
>>>
____________________________________________________________<br>
>>> You received this message
as a subscriber on the list:<br>
>>> <a
moz-do-not-send="true"
href="mailto:community@lists.idcommons.net"
target="_blank">community@lists.idcommons.net</a><br>
>>> To be removed from the
list, send any message to:<br>
>>> <a
moz-do-not-send="true"
href="mailto:community-unsubscribe@lists.idcommons.net"
target="_blank">community-unsubscribe@lists.idcommons.net</a><br>
>>><br>
>>> For all list information
and functions, see:<br>
>>> <a
moz-do-not-send="true"
href="http://lists.idcommons.net/lists/info/community"
target="_blank">http://lists.idcommons.net/lists/info/community</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Nat Sakimura (=nat)<br>
> Chairman, OpenID Foundation<br>
> <a moz-do-not-send="true"
href="http://nat.sakimura.org/"
target="_blank">http://nat.sakimura.org/</a><br>
> @_nat_en<br>
><br>
>
_______________________________________________<br>
> specs mailing list<br>
> <a moz-do-not-send="true"
href="mailto:specs@lists.openid.net"
target="_blank">specs@lists.openid.net</a><br>
> <a moz-do-not-send="true"
href="http://lists.openid.net/mailman/listinfo/openid-specs"
target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a><br>
><br>
><br>
>
_______________________________________________<br>
> specs mailing list<br>
> <a moz-do-not-send="true"
href="mailto:specs@lists.openid.net"
target="_blank">specs@lists.openid.net</a><br>
> <a moz-do-not-send="true"
href="http://lists.openid.net/mailman/listinfo/openid-specs"
target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a><br>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
specs mailing list
<a moz-do-not-send="true" href="mailto:specs@lists.openid.net" target="_blank">specs@lists.openid.net</a>
<a moz-do-not-send="true" href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a>
</pre>
</blockquote>
<br>
</div>
</div>
<span class="HOEnZb"><font color="#888888">
<div>-- <br>
<a moz-do-not-send="true"
href="http://connect.me/gffletch" title="View
full card on Connect.Me" target="_blank"><img
src="cid:part28.07090705.05010104@aol.com"
alt="George Fletcher" height="113" width="359"></a></div>
</font></span></div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<a href="http://connect.me/gffletch" title="View full card on
Connect.Me"><img src="cid:part30.07070106.02050507@aol.com"
alt="George Fletcher" height="113" width="359"></a></div>
</body>
</html>