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

Hi Melvin,

the straightforward way would be to create another authz scheme. BUT the most important question is, what do you want to achieve? 

1) You just need a hint? So you don't rely on this data for access control. Use any header you want.
2) You want to control access to a resource. This requires trustworthy/authenticated identity data. Here the obvious way is an OAuth access token (authorization header,  BEARER scheme). In your specific case, it might be required to even specify the tokens format. JSON web tokens would be the right choice in my opinion.

Why does you concept require the user id to be a URL?

Regards,
Torsten.



Melvin Carvalho <melvincarvalho@gmail.com> schrieb:

>On 18 July 2013 19:38, Torsten Lodderstedt <torsten@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@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@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@gmail.com>
>>>> wrote:
>>>>
>>>> >
>>>> >
>>>> >
>>>> > On 18 July 2013 01:06, Nat Sakimura <sakimura@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@identitywoman.net>
>>>> > Date: 2013/7/18
>>>> > Subject: Re: [community] from W3C….Fwd: Proposal: "User" header
>field
>>>> > To: Nat Sakimura <sakimura@gmail.com>
>>>> > Cc: "community@lists.idcommons.net"
><community@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@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@w3.org
>>>> >>>> Date:      Sat, 13 Jul 2013 12:08:37 -0400
>>>> >>>> From:      Joe <presbrey@gmail.com>
>>>> >>>> To:        Melvin Carvalho <melvincarvalho@gmail.com>
>>>> >>>> CC:        public-rww <public-rww@w3.org>
>>>> >>>>
>>>> >>>> Great job Melvin!
>>>> >>>>
>>>> >>>> Data.fm sends the User header already :)
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> On Jul 13, 2013, at 10:55 AM, Melvin Carvalho <
>>>> melvincarvalho@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@lists.idcommons.net
>>>> >>> To be removed from the list, send any message to:
>>>> >>>     community-unsubscribe@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@lists.openid.net
>>>> > http://lists.openid.net/mailman/listinfo/openid-specs
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > specs mailing list
>>>> > specs@lists.openid.net
>>>> > http://lists.openid.net/mailman/listinfo/openid-specs
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> specs mailing
>listspecs@lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs
>>>
>>>
>>> --
>>> [image: George Fletcher] <http://connect.me/gffletch>
>>>
>>> ------------------------------
>>>
>>> specs mailing list
>>> specs@lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>>
>>>