On 18 July 2013 01:54, John Kemp <[email protected]
<mailto:[email protected]>> wrote:
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?
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.
'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?
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.
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.
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.
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)?
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?
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?
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
John
On Jul 17, 2013, at 7:41 PM, Melvin Carvalho
<[email protected]
<mailto:[email protected]>> wrote:
>
>
>
> On 18 July 2013 01:06, Nat Sakimura
<[email protected] <mailto:[email protected]>>
wrote:
> Hi.
>
> I am forwarding the mail in the identity
commons list.
>
> 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.
>
> Their proposal is to include
>
> User: http://this.is.the/user/identifier
>
> in the HTTP header.
>
> Could those of you active in W3C reach out to them?
>
> As I have written below, if it were to just
include the IdP address as a hint, I am kind of fine.
>
> Thanks for sharing this. Since this was my
proposal, I hope I can shed a bit of light light.
>
> 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.
>
> Yes, the idea is that it is just a hint. Note
the text:
>
> "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."
>
> 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.
>
>
> Best,
>
> Nat
>
> ---------- Forwarded message ----------
> From: Kaliya "Identity Woman"
<[email protected]
<mailto:[email protected]>>
> Date: 2013/7/18
> Subject: Re: [community] from W3C….Fwd:
Proposal: "User" header field
> To: Nat Sakimura <[email protected]
<mailto:[email protected]>>
> Cc: "[email protected]
<mailto:[email protected]>"
<[email protected]
<mailto:[email protected]>>
>
>
> Yes Nat, Thats sort of what I got from reading it.
>
> Who among us is very active in the W3C world?
>
> If no one should we be figuring out who should be?
>
> Should we write them a letter asking them to
send "identitish" proposals to IIW? or other
forums for good input?
>
> Maybe we should write something that is like
understanding identity basics for technical
specification folks across a range of standards
bodies?
>
> - Kaliya
>
> On Jul 17, 2013, at 3:32 AM, Nat Sakimura wrote:
>
>> Whoa, what's that?!
>>
>> That's not only useless but actually harmful.
>>
>> I can kind of see some utility in sending the
IdP address, but not the user.
>>
>> =nat via iPhone
>>
>> On Jul 16, 2013, at 7:39, "Kaliya \"Identity
Woman\"" <[email protected]
<mailto:[email protected]>> wrote:
>>
>>> Hi folks,
>>> Apparently the W3C wants to send "user"
names along in HTTP headers.
>>> I thought some folks who know about identity
and how it does/could/should work might be up for
chiming in over there.
>>> It seems like Authentication of identity
might be a good thing rather then just assertion.
>>> - Kaliya
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> From: Christine
>>>
>>>> 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: http://www.w3.org/community/rww/
>>>>
>>>> I sent you a message a few weeks ago about
Tabulator.
>>>>
>>>> See below messages about User header field.
If you are not already a member, I recommend you
join and contribute!
>>>>
>>>> Christine
>>>>
>>>>
>>>> -------- Original Message --------
>>>> Subject: Re: Proposal: "User" header field
>>>> Resent-Date: Sat, 13 Jul 2013 16:19:02 +0000
>>>> Resent-From: [email protected]
<mailto:[email protected]>
>>>> Date: Sat, 13 Jul 2013 12:08:37 -0400
>>>> From: Joe <[email protected]
<mailto:[email protected]>>
>>>> To: Melvin Carvalho
<[email protected]
<mailto:[email protected]>>
>>>> CC: public-rww <[email protected]
<mailto:[email protected]>>
>>>>
>>>> Great job Melvin!
>>>>
>>>> Data.fm sends the User header already :)
>>>>
>>>>
>>>>
>>>>
>>>> On Jul 13, 2013, at 10:55 AM, Melvin
Carvalho <[email protected]
<mailto:[email protected]>> wrote:
>>>>
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> The suggestion has been to choose another
header, so I thought that "User" might be a good
candidate, since we have User Agent arleady.
>>>>>
>>>>> Here's the proposed text:
>>>>>
>>>>> [[
>>>>> User
>>>>>
>>>>> 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
>>>>> User = "User" ":" URI
>>>>>
>>>>> An example is:
>>>>>
>>>>> User:
http://www.w3.org/People/Berners-Lee/card#i
>>>>> 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.
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>> ]]
>>>>>
>>>>> Feedback welcome!
>>>>>
>>>>
>>>>
>>>
>>>
>>>
____________________________________________________________
>>> You received this message as a subscriber on
the list:
>>> [email protected]
<mailto:[email protected]>
>>> To be removed from the list, send any message to:
>>> [email protected]
<mailto:[email protected]>
>>>
>>> For all list information and functions, see:
>>> http://lists.idcommons.net/lists/info/community
>
>
>
>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
> _______________________________________________
> specs mailing list
> [email protected]
<mailto:[email protected]>
>
http://lists.openid.net/mailman/listinfo/openid-specs
>
>
> _______________________________________________
> specs mailing list
> [email protected]
<mailto:[email protected]>
>
http://lists.openid.net/mailman/listinfo/openid-specs
_______________________________________________
specs mailing list
[email protected] <mailto:[email protected]>
http://lists.openid.net/mailman/listinfo/openid-specs
