Final: OpenID Attribute Exchange 1.0 – Final: 5. Fetch Message : 俺約/メモ



5.  Fetch Message

The fetch message is used to retrieve personal identity attributes from an OpenID Provider.


5.1.  Fetch Request Format

With the exception of "", all of the following request fields are OPTIONAL, though at least one of "" or "" MUST be specified in the request, and any attribute alias present in a "" or "" parameter MUST have an associated "<alias>" parameter. The supported length for attribute aliases MUST be at least 32 characters.

( 以外はオプショナル。 ただし、何かしら指定したら if_available か required は指定すること。エイリアスのサイズは32文字。)

Multiple attribute aliases in the "" and "" directives are separated with a comma, ",".

REQUIRED. Value: "fetch_request".<alias>

The value of this parameter specifies the type identifier URI of a requested attribute. The <alias> will further be used to identify the attribute being exchanged.

Attribute aliases MUST NOT contain newline and colon characters, as specified in the Data Formats / Protocol Messages section of [OpenID.authentication‑2.0] (, “OpenID Authentication 2.0 – Final,” August 2007.); they also MUST NOT contain commas (",") and periods (".").

コロン、改行(\n), カンマ、ピリオドは<alias>を含まない

Value: an attribute alias, or a list of aliases corresponding to the URIs defined by "<alias>" parameters. Multiple attribute aliases are separated with a comma, ",".


By requesting attributes using this field, a hint is sent to the OP about the RP’s requirements for offering certain functionality and should be used by the OP to help the user decide what attributes to release. RP’s requirements should not be enforced by the OP.

The RP should offer, out of band of attribute exchange, an alternate method of collecting the attributes it needs, if they weren’t obtained via attribute exchange.

AX以外でやりたかったら out of band の属性交換を要求すべき。

Value: an attribute alias, or a list of aliases corresponding to the URIs defined by "<alias>" parameters. Multiple attribute aliases are separated with a comma, ",".

Attributes requested using this field are deemed optional by the RP; the RP should be able to complete the interaction with the user even if values are not provided by the OP for the optional attributes.


The number of values for the specified attribute alias the Relying Party wishes to receive from the OpenID Provider. If present, the value MUST be greater than zero, or the special value "unlimited" which signifies that the RP is requesting as many values as the OP has for the attribute. If absent, exactly one value is requested.


OpenID Providers MAY return less than or the exact number of values speficied by this field for the associated attribute, but MUST NOT return more than the number of requested values for the attribute.


If present, the OpenID Provider may re-post the fetch response message to the specified URL at some time after the initial response has been sent, using a OpenID Authentication Positive Assertion. If the OpenID Provider supports this feature it MUST return the parameter as part of the fetch response message. If it does not support this feature it may legally ignore this parameter.

update_url が指定してあれば、OPはfetchの応答メッセージをそのURLにあとで最POSTしてよい。OpenID AuthenticationのPositive Assertionに乗せること。もしもOPがこの機能をサポートしていたら,fetch 応答メッセージこのパラメータをエコーして返す。サポートしないのであれば無視する。

The value of the "" field MUST be used as value for "openid.return_to" field of the underlying OpenID Authentication Positive Assertion of the fetch response update.

update_urlの値はopenid.return_to フィールドの値として使われる。OpenID AuthenticationのPostive Assertionとして返されるので。

(return_toとupdate_urlの関係はこんな感じ? )

The "" value MUST also match the realm specified in the underlying OpenID message of the fetch request, if a "openid.realm" field is present. The matching rules are the ones specified in the "Realms" section of the OpenID Authentication protocol.

update_url の値は fetchリクエストの realm にマッチしないといけません(openid.realmがあれば)。OpenID Authentication の "Realms"を参照してください。

This "unsolicited" response message would be generated in response to an attribute information update, and would contain the updated data. The OP should obtain the user’s consent for resending the updated data to the RPs, as with any OpenID Positive Assertion.


The relying party may include transaction data encoded in the URL such that it contains enough information to match the attribute information to the identity subject. Additional information may be encoded in the URL by the relying party as necessary.


If an RP wishes to receive no further updates for an attribute, it MAY return the HTTP 404 response code to the corresponding "update_url". OPs MAY decide to stop sending updates after encountering 404 response codes.

RPが属性更新をこれ以上受け取りたくなければ、HTTP404を "update_url"に返してください。OPは404が帰ってきたら更新を送るのをやめます。

This example requests the required full name and gender information, and the optional favourite dog and movie information. The Relying Party is interested in up to three favorite movies associated with the subject identifier.,gender,fav_movie

Final: OpenID Attribute Exchange 1.0 – Final

カテゴリー: 未分類 パーマリンク


以下に詳細を記入するか、アイコンをクリックしてログインしてください。 ロゴ アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中