Re: [community] from W3C….Fwd: Proposal: "User" header field
Melvin Carvalho
melvincarvalho at gmail.com
Fri Jan 17 17:08:35 UTC 2014
On 16 January 2014 10:00, Nat Sakimura <sakimura at 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 at gmail.com>
>
>>
>>
>>
>> On 25 December 2013 18:14, Phil Hunt <phil.hunt at 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 at gmail.com>
>>> wrote:
>>>
>>>
>>>
>>>
>>> On 19 July 2013 16:00, n-sakimura <n-sakimura at 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 at gmail.com
>>>>>> <mailto:melvincarvalho at gmail.com>> schrieb:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 18 July 2013 19:38, Torsten Lodderstedt
>>>>>> <torsten at lodderstedt.net <mailto: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
>>>>>> <mailto: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
>>>>>>> <mailto: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
>>>>>>> <mailto:melvincarvalho at gmail.com>> wrote:
>>>>>>>
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> > On 18 July 2013 01:06, Nat Sakimura
>>>>>>> <sakimura at gmail.com <mailto: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
>>>>>>> <mailto: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
>>>>>>> <mailto:sakimura at gmail.com>>
>>>>>>> > Cc: "community at lists.idcommons.net
>>>>>>> <mailto:community at lists.idcommons.net>"
>>>>>>> <community at lists.idcommons.net
>>>>>>> <mailto: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
>>>>>>> <mailto: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
>>>>>>> <mailto:public-rww at w3.org>
>>>>>>> >>>> Date: Sat, 13 Jul 2013 12:08:37 -0400
>>>>>>> >>>> From: Joe <presbrey at gmail.com
>>>>>>> <mailto:presbrey at gmail.com>>
>>>>>>> >>>> To: Melvin Carvalho
>>>>>>> <melvincarvalho at gmail.com
>>>>>>> <mailto:melvincarvalho at gmail.com>>
>>>>>>> >>>> CC: public-rww <public-rww at w3.org
>>>>>>> <mailto: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
>>>>>>> <mailto: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
>>>>>>> <mailto:community at lists.idcommons.net>
>>>>>>>
>>>>>>> >>> To be removed from the list, send any
>>>>>>> message to:
>>>>>>> >>> community-unsubscribe at 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 at lists.openid.net
>>>>>>> <mailto:specs at lists.openid.net>
>>>>>>>
>>>>>>> >
>>>>>>> http://lists.openid.net/
>>>>>>> mailman/listinfo/openid-specs
>>>>>>> >
>>>>>>> >
>>>>>>> > ______________________________
>>>>>>> _________________
>>>>>>> > specs mailing list
>>>>>>> > specs at lists.openid.net
>>>>>>> <mailto:specs at lists.openid.net>
>>>>>>>
>>>>>>> >
>>>>>>> http://lists.openid.net/
>>>>>>> mailman/listinfo/openid-specs
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> specs mailing list
>>>>>>> specs at lists.openid.net <mailto:
>>>>>>> specs at lists.openid.net>
>>>>>>> http://lists.openid.net/
>>>>>>> mailman/listinfo/openid-specs
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> George Fletcher <http://connect.me/gffletch>
>>>>>>
>>>>>> ------------------------------
>>>>>> ------------------------------------------
>>>>>>
>>>>>> specs mailing list
>>>>>> specs at lists.openid.net <mailto:
>>>>>> 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
>>>>>
>>>>>
>>>>
>>>> --
>>>> Nat Sakimura (n-sakimura at nri.co.jp)
>>>> Nomura Research Institute, Ltd.
>>>> Tel:+81-3-6274-1412 Fax:+81-3-6274-1547
>>>>
>>>> 本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信 することを意図しております。意図された受取人以外の方によるこれらの情報の
>>>> 開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メール を受信された場合は、申し訳ございませんが、送信者までお知らせいただき、受
>>>> 信されたメールを削除していただきますようお願い致します。
>>>> PLEASE READ:
>>>> The information contained in this e-mail is confidential and intended
>>>> for the named recipient(s) only.
>>>> If you are not an intended recipient of this e-mail, you are hereby
>>>> notified that any review, dissemination, distribution or duplication of
>>>> this message is strictly prohibited. If you have received this message in
>>>> error, please notify the sender immediately and delete your copy from your
>>>> system.
>>>>
>>>>
>>> _______________________________________________
>>> 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
>>
>>
>
>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20140117/9ff7c792/attachment-0001.html>
More information about the specs
mailing list