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

Melvin Carvalho melvincarvalho at gmail.com
Thu Jul 18 17:56:35 UTC 2013


On 18 July 2013 19:38, Torsten Lodderstedt <torsten at lodderstedt.net> 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?
>

Hi Thorsten, thanks for the tip.  If there's an existing way to identify to
a server a user's URL via a header, I'd love to learn more about that.
It's preferable to reuse existing tools, if possible, than to create
something new.


>
>
>
> George Fletcher <gffletch at aol.com> schrieb:
>
>> I'm a little confused...  first the spec says
>>
>> 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.
>>
>> and then you follow that up with
>>
>> 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.
>>
>> 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?
>>
>> Thanks,
>> George
>>
>> On 7/18/13 12:49 PM, Melvin Carvalho wrote:
>>
>>
>>
>>
>> On 18 July 2013 01:54, John Kemp <john at jkemp.net> 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 <melvincarvalho at gmail.com>
>>> wrote:
>>>
>>> >
>>> >
>>> >
>>> > On 18 July 2013 01:06, Nat Sakimura <sakimura at gmail.com> 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" <kaliya-lists at identitywoman.net>
>>> > Date: 2013/7/18
>>> > Subject: Re: [community] from W3C….Fwd: Proposal: "User" header field
>>> > To: Nat Sakimura <sakimura at gmail.com>
>>> > Cc: "community at lists.idcommons.net" <community at lists.idcommons.net>
>>> >
>>> >
>>> > 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\"" <
>>> kaliya-lists at identitywoman.net> 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:       public-rww at w3.org
>>> >>>> Date:      Sat, 13 Jul 2013 12:08:37 -0400
>>> >>>> From:      Joe <presbrey at gmail.com>
>>> >>>> To:        Melvin Carvalho <melvincarvalho at gmail.com>
>>> >>>> CC:        public-rww <public-rww at w3.org>
>>> >>>>
>>> >>>> Great job Melvin!
>>> >>>>
>>> >>>> Data.fm sends the User header already :)
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> On Jul 13, 2013, at 10:55 AM, Melvin Carvalho <
>>> melvincarvalho at gmail.com> 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:
>>> >>>     community at lists.idcommons.net
>>> >>> To be removed from the list, send any message to:
>>> >>>     community-unsubscribe at lists.idcommons.net
>>> >>>
>>> >>> 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
>>> > specs at lists.openid.net
>>> > http://lists.openid.net/mailman/listinfo/openid-specs
>>> >
>>> >
>>> > _______________________________________________
>>> > specs mailing list
>>> > specs at lists.openid.net
>>> > http://lists.openid.net/mailman/listinfo/openid-specs
>>>
>>>
>>
>>
>> _______________________________________________
>> specs mailing listspecs at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs
>>
>>
>> --
>> [image: George Fletcher] <http://connect.me/gffletch>
>>
>> ------------------------------
>>
>> specs mailing list
>> specs at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20130718/efd6fa22/attachment.html>


More information about the specs mailing list