- From: Phil Hunt <phil.hunt@oracle.com>
- Date: Wed, 25 Dec 2013 10:14:47 -0700
- To: Melvin Carvalho <melvincarvalho@gmail.com>
- Cc: n-sakimura <n-sakimura@nri.co.jp>, OpenID Specs Mailing List <specs@openid.net>, public-rww <public-rww@w3.org>
- Message-Id: <E03BB0B0-8D30-409D-9216-4B0EB4FD2680@oracle.com>
Do you mean a URL for session state or a 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
>
> 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
> 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….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
>>
>> 本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信 することを意図しております。意図された受取人以外の方によるこれらの情報の 開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メール を受信された場合は、申し訳ございませんが、送信者までお知らせいただき、受 信されたメールを削除していただきますようお願い致します。
>> 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@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
Received on Wednesday, 25 December 2013 17:15:30 UTC