- From: Nat Sakimura <sakimura@gmail.com>
- Date: Thu, 16 Jan 2014 18:00:58 +0900
- To: Melvin Carvalho <melvincarvalho@gmail.com>
- Cc: Phil Hunt <phil.hunt@oracle.com>, OpenID Specs Mailing List <specs@openid.net>, public-rww <public-rww@w3.org>
- Message-ID: <CABzCy2Cx623Rp4RmnmpMdQGsSskYH8UbXZdnOKXaT82XKvo+Pw@mail.gmail.com>
Perhaps you might want to consider sending acct: URI.
Then, you can leverage WebFinger for the discovery process.
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 Thursday, 16 January 2014 09:01:37 UTC