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

On 16 January 2014 10:00, Nat Sakimura <sakimura@gmail.com> wrote:

> Perhaps you might want to consider sending acct: URI.
> Then, you can leverage WebFinger for the discovery process.
>

Sure, that works too


>
>
> 2013/12/26 Melvin Carvalho <melvincarvalho@gmail.com>
>
>>
>>
>>
>> On 25 December 2013 18:14, Phil Hunt <phil.hunt@oracle.com> wrote:
>>
>>> Do you mean a URL for session state or a URL for the User (subject)
>>> authenticated?
>>>
>>
>> The URL for the User (subject) authenticated.
>>
>>
>>>
>>> Phil
>>>
>>> On Dec 25, 2013, at 6:50, Melvin Carvalho <melvincarvalho@gmail.com>
>>> wrote:
>>>
>>>
>>>
>>>
>>> On 19 July 2013 16:00, n-sakimura <n-sakimura@nri.co.jp> wrote:
>>>
>>>> Actually, in the pure sense, OAuth Bearer Authorization is just
>>>> representing the Authorization = Access Grant, and the entity who is
>>>> presenting the token is not necessarily the entity who got authenticated
>>>> and obtained the token. That's the beauty of bearer instruments [1]. (Most
>>>> common bearer instrument is physical money such as bank notes and coins.)
>>>> It makes the late binded delegation / power of attorney easy.
>>>>
>>>> However, this feature makes the bearer token a dangerous thing to use
>>>> as authentication / representation of identity. To use it as an
>>>> authentication token, the following assumptions MUST be fulfilled.
>>>>
>>>> 1. Bearer Token is naver used by any entity but the entity who
>>>>    obtained it.
>>>>
>>>> 2. It is possible to verify the audience of the token.
>>>>
>>>> These conditions are generally not met.
>>>>
>>>> That's why OpenID Connect introduced ID Token, which is a registered
>>>> instrument rather than a bearer instrument.
>>>>
>>>> If you were just concerned with authentication (= process of
>>>> identifying the entity in front of your service), then I would stick with
>>>> OpenID Connect. Create an OAuth authorization request with scope=openid as:
>>>>
>>>> https://server.example.com/authorize?
>>>>     response_type=code
>>>>     &client_id=s6BhdRkqt3
>>>>     &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
>>>>     &scope=openid
>>>>     &state=af0ifjsldkj
>>>>
>>>> Then, you will get an authorization code.
>>>>
>>>> Send the authorization code to the authorization endpoint. This is a
>>>> plain OAuth 2.0 Authorization request again:
>>>>
>>>> POST /token HTTP/1.1
>>>>   Host: server.example.com
>>>>   Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
>>>>   Content-Type: application/x-www-form-urlencoded
>>>>
>>>>   grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
>>>>     &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
>>>>
>>>> It will respond with JSON such as:
>>>>
>>>>   {
>>>>    "access_token":"SlAV32hkKG",
>>>>    "token_type":"Bearer",
>>>>    "expires_in":3600,
>>>>    "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
>>>>    "id_token":"eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso"
>>>>   }
>>>>
>>>> id_token is JWT encoded JSON. When you decode it, you will get
>>>> something like:
>>>>
>>>>
>>>>   {
>>>>    "iss": "https://server.example.com",
>>>>    "sub": "alice",
>>>>    "aud": "https://blog.example.com",
>>>>    "exp": 1311281970,
>>>>    "iat": 1311280970
>>>>   }
>>>>
>>>> You can put these in the session cookie for easy access from the web
>>>> application such as blog subsequently. Make sure that you store them in the
>>>> cookie that was bound for the state parameter value that came back with
>>>> code.
>>>>
>>>> This I think solves your use case, does it not?
>>>> That's about the bear minimum you have to do to do the authentication...
>>>>
>>>
>>> I finally got some time to read through this, I've looked at OAuth,
>>> Bearer Token, Basic and Digest Auth documentation.  There would appear to
>>> be no 100% straightforward way for clients and servers to indicate a URL
>>> that controls that session.  I've put this proposal in our wiki page,
>>> including the proposed text, some background, use cases and
>>> implementations.  One use case is for client side apps to be able determine
>>> the user they are dealing with and render the page accordingly.
>>>
>>> http://www.w3.org/community/rww/wiki/User_Header
>>>
>>> Feedback welcome!  (And Merry Christmas :))
>>>
>>> [[
>>>  Introduction
>>>
>>> There would appear to be no simple way in HTTP, to indicate an HTTP URL
>>> referring to the User that is currently controlling a session. This would
>>> be useful for both clients and servers, and, in particular to allow client
>>> side applications to personalize a page. Architecturally, a clean, modular,
>>> separation of identity and verified identity (authentication) may be
>>> beneficial.
>>>
>>> There has been some discussion on whether the "From" header can be used
>>> to identify a user in HTTP, but for historical reasons it's limited to
>>> email, any change to this would likely get some pushback from the IETF.
>>>
>>> The suggestion has been to choose another header, and the latest
>>> proposal is to create a new User header. The text below is very similar to
>>> the existing "From" header
>>>  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 <http://tools.ietf.org/html/rfc3986>
>>>
>>>    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.
>>>
>>> Additionally, servers MAY send this header, having verified the identity
>>> of a user, enabling client side apps to personalize a page.
>>>  Use Cases  Page Personalization
>>>
>>> The user header would allow a personalization of pages for client side
>>> apps. One might display a user's name, avatar and homepage, by
>>> dereferencing the URL and finding out more information.
>>>  Server Response
>>>
>>> A server may respond with a user header to tell a client who is in
>>> control of the current session. The client may use this information to
>>> access locally stored information.
>>>  Endpoint Discovery
>>>
>>> By dereferencing a URL it may be possible to find further endpoints, for
>>> example, in order to authenticate the idenitity.
>>>  Identity Verification
>>>
>>> While the user header is simply a hint, it is possible to imagine a
>>> scenario where more information is provided, such as a key pair in TLS, or
>>> additional information such as the "Authorization" header, to enable the
>>> server to verify the authenticity of the User. For example using Basic Auth
>>> the user may not contain the ":" character, so this would, enable a URL to
>>> be associated with a password.
>>>  Implementations
>>>
>>>    - OpenLink Data Spaces <http://ods.openlinksw.com/wiki/ODS/>
>>>    - rww.io
>>>    - data.fm
>>>
>>>  ]]
>>>
>>>
>>>
>>>>
>>>> [1] See http://en.wikipedia.org/wiki/Bearer_instrument
>>>>
>>>>
>>>>
>>>> (2013/07/19 18:23), Torsten Lodderstedt wrote:
>>>>
>>>>> Hi Melvin,
>>>>>
>>>>> <snip>
>>>>>
>>>>>>
>>>>>>     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?
>>>>>>
>>>>>>
>>>>>> Hi Thorsten, the concept does not require a URL, but it needs a header
>>>>>> that does not *forbid* a URL, and this was the issue with "From".  The
>>>>>> reason is that many people host user profiles on a web URL, so we
>>>>>> would like to be inclusive of that group of people.
>>>>>>
>>>>>> I'm not 100% familiar with all the latest changes to OAuth / OpenID
>>>>>> Connect, but if there is something in those specifications that could
>>>>>> be reused to send an identity to a server, and you could point me to
>>>>>> what to read up on, I'd be grateful.
>>>>>>
>>>>>
>>>>> sure.
>>>>>
>>>>> Latest information regarding OAuth can be obtained on the WG page
>>>>> (https://datatracker.ietf.org/wg/oauth/)
>>>>>
>>>>> Sending a token to a protected resource uses the BEARER authorization
>>>>> scheme (http://tools.ietf.org/html/rfc6750) and works like this:
>>>>>
>>>>>       GET /resource HTTP/1.1
>>>>>       Host: server.example.com
>>>>>       Authorization: Bearer mF_9.B5f-4.1JqM
>>>>>
>>>>> "mF_9.B5f-4.1JqM" is the actual token typically containing identity and
>>>>> authz data about the user on whos behalf the request is being
>>>>> performed.
>>>>>
>>>>>  From the client's perspective, this token is opaque and can be utilize
>>>>> any format the OAuth authorization server and the respective resource
>>>>> server agreed upon. The WG also specified a certain token format, which
>>>>> is called JSON Web Token
>>>>> (http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-10). The
>>>>> format allows to represent identity data (so-called claims) in a
>>>>> cryptographically protected way. One of those claims is "sub", an user
>>>>> account identifier which may also be a URI. A typical JWT contains
>>>>> claims identifying the IDP (iss), the resource server the token is
>>>>> targeted at (aud) and the user id (sub).
>>>>>
>>>>> This is an example JWT (prior signature processing etc):
>>>>>
>>>>>       {"iss":"https://idp.mydomain.com",
>>>>>         "aud":"https://resourceserver.otherdomain.org"
>>>>>        "exp":1300819380,
>>>>>        "sub":"http://this.is.the/user/bmeier
>>>>> <http://this.is.the/user/identifier>"}
>>>>>
>>>>> regards,
>>>>> Torsten.
>>>>>
>>>>>
>>>>>>     Regards,
>>>>>>     Torsten.
>>>>>>
>>>>>>
>>>>>>
>>>>>>     Melvin Carvalho <melvincarvalho@gmail.com
>>>>>>     <mailto:melvincarvalho@gmail.com>> schrieb:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>         On 18 July 2013 19:38, Torsten Lodderstedt
>>>>>>         <torsten@lodderstedt.net <mailto: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
>>>>>>             <mailto: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
>>>>>>>                 <mailto: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
>>>>>>>                     <mailto:melvincarvalho@gmail.com>> wrote:
>>>>>>>
>>>>>>>                     >
>>>>>>>                     >
>>>>>>>                     >
>>>>>>>                     > On 18 July 2013 01:06, Nat Sakimura
>>>>>>>                     <sakimura@gmail.com <mailto: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
>>>>>>>                     <mailto:kaliya-lists@identitywoman.net>>
>>>>>>>                     > Date: 2013/7/18
>>>>>>>                     > Subject: Re: [community] from W3C$B!D(B.Fwd:
>>>>>>>                     Proposal: "User" header field
>>>>>>>                     > To: Nat Sakimura <sakimura@gmail.com
>>>>>>>                     <mailto:sakimura@gmail.com>>
>>>>>>>                     > Cc: "community@lists.idcommons.net
>>>>>>>                     <mailto:community@lists.idcommons.net>"
>>>>>>>                     <community@lists.idcommons.net
>>>>>>>                     <mailto: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
>>>>>>>                     <mailto: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
>>>>>>>                     <mailto:public-rww@w3.org>
>>>>>>>                     >>>> Date:  Sat, 13 Jul 2013 12:08:37 -0400
>>>>>>>                     >>>> From:      Joe <presbrey@gmail.com
>>>>>>>                     <mailto:presbrey@gmail.com>>
>>>>>>>                     >>>> To:  Melvin Carvalho
>>>>>>>                     <melvincarvalho@gmail.com
>>>>>>>                     <mailto:melvincarvalho@gmail.com>>
>>>>>>>                     >>>> CC:  public-rww <public-rww@w3.org
>>>>>>>                     <mailto: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
>>>>>>>                     <mailto: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
>>>>>>>                     <mailto:community@lists.idcommons.net>
>>>>>>>
>>>>>>>                     >>> To be removed from the list, send any
>>>>>>> message to:
>>>>>>>                     >>> community-unsubscribe@lists.idcommons.net
>>>>>>>                     <mailto: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
>>>>>>>                     <mailto:specs@lists.openid.net>
>>>>>>>
>>>>>>>                     >
>>>>>>>                     http://lists.openid.net/
>>>>>>> mailman/listinfo/openid-specs
>>>>>>>                     >
>>>>>>>                     >
>>>>>>>                     > ______________________________
>>>>>>> _________________
>>>>>>>                     > specs mailing list
>>>>>>>                     > specs@lists.openid.net
>>>>>>>                     <mailto:specs@lists.openid.net>
>>>>>>>
>>>>>>>                     >
>>>>>>>                     http://lists.openid.net/
>>>>>>> mailman/listinfo/openid-specs
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                 _______________________________________________
>>>>>>>                 specs mailing list
>>>>>>>                 specs@lists.openid.net  <mailto:
>>>>>>> specs@lists.openid.net>
>>>>>>>                 http://lists.openid.net/
>>>>>>> mailman/listinfo/openid-specs
>>>>>>>
>>>>>>
>>>>>>                 --
>>>>>>                 George Fletcher <http://connect.me/gffletch>
>>>>>>
>>>>>>                 ------------------------------
>>>>>> ------------------------------------------
>>>>>>
>>>>>>                 specs mailing list
>>>>>>                 specs@lists.openid.net  <mailto:
>>>>>> 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
>>>>>
>>>>>
>>>>
>>>> --
>>>> Nat Sakimura (n-sakimura@nri.co.jp)
>>>> Nomura Research Institute, Ltd.
>>>> Tel:+81-3-6274-1412 Fax:+81-3-6274-1547
>>>>
>>>> $BK\%a!<%k$K4^$^$l$k>pJs$O5!L)>pJs$G$"$j!"08@h$K5-:\$5$l$F$$$kJ}$N$_$KAw?.(B $B$9$k$3$H$r0U?^$7$F$*$j$^$9!#0U?^$5$l$?pJs$N(B
>>>> $B3+<(!"J#@=!":FG[I[$dE>Aw$J$I0l@Z$NMxMQ$,6X;_$5$l$F$$$^$9!#8m$C$FK\%a!<%k(B $B$rl9g$O!"?=$7Lu$4$6$$$^$;$s$,!"Aw?.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
>>
>>
>
>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>

Received on Friday, 17 January 2014 17:09:08 UTC