This English version is only a translation of the Japanese version, and is provided for reference only. In
case of discrepancy between the Japanese and English versions, the Japanese version shall prevail andbe treated as the correct version.

System Administration Standards for the GakuNin Academic Access
Management Federation (Ver. 1.2)
Table of Contents
1. SAML Technical Standards
1.1) SAML V2.0 Core
1.2) SAML V2.0 Profiles
1.3) SAML V2.0 Metadata
2. Protocol
2.1) Authentication Request
2.2) Authentication Response
2.3) Shibboleth
3. Attribute Information
3.1) Using Attribute Information
3.2) Attribute Information Trustworthiness3.3) Attribute Information Validation
3.4) Attribute Information Levels3.5) Scope
4. Metadata4.1) Metadata Specifications
4.2) Kinds of Metadata4.3) Submission of Entity Metadata4.4) Contents of Entity Metadata4.5) Entity Metadata <Organization> Element
4.6) Entity Metadata ID
4.7) Submission and Publishing of Federation Metadata4.8) Acquisition and Installation of Federation Metadata4.9) Updating of Federation Metadata4.10) Federation Metadata Signature Validation
5. Discovery Service
6. Federation Support
7. Certificate Use7.1) Certificate for Federation Metadata Signature
7.2) Validation of a Federation Metadata Signature Certificate
17.3) Trusted Certificate Authority
7.4) What to Do When a Private Key is Compromised
7.5) Direct SOAP Connection
8. Security
8.1) User ID Management
8.2) User ID Recycling
8.3) Assurance of the Sameness of a Claimant
8.4) ID Use in SP
8.5) User Information Maintenance8.6) User Consent
8.7) Log Storage
8.8) Member Organization Responsibilities
9. Entities for GakuNin Administrative Use9.1) GakuNin IdP
9.2) Attribute Viewer Service
Appendix 1. GakuNin Supported Attribute Information Specifications

2

These Standards govern matters relating to system administration of an identity
provider (IdP) or service provider (SP) participating in the GakuNin Academic Access
Management Federation (hereinafter called “GakuNin”). They have been drawn up by
Organization for Science Network Operations and Coordination in the National
Institute of Informatics. They also cover Certification Working Subcommittee(hereinafter called “ＣWSC”).
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to
be interpreted as described in RFC 2119.

1. SAML Technical Standards
The SAML technical standards used in GakuNin SHALL be based on the following
standards specified by the OASIS Security Services Technical Committee.

1.1) SAML V2.0 Core
(http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf)
Specifies the technical requirements for conformance with SAML V2.0 and the
documents of which they consist.

1.2) SAML V2.0 Profiles(http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf)
Specifies the identifiers used between systems, binding support, and use ofcertificates and keys.

1.3) SAML V2.0 Metadata(http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf)
Specifies the rules for standardized notation of metadata.

2. Protocol
These Standards are designed so that an IdP or SP (hereinafter called an “entity”)
participating in GakuNin will be able to provide as broad a range of services as
possible. To this end, all entities participating in GakuNin SHOULD use the protocol
standardized within GakuNin. The protocol SHALL meet the requirements herein
for authentication request and authentication response.
As software for use in GakuNin, Shibboleth is RECOMMENDED as an example ofsoftware implementing the above kind of protocol.

32.1) Authentication Request
HTTP-bound SAML protocol authentication request messages SHOULD be
implemented in conformity with the Web Browser SSO Profile specifications
stipulated in the SAML technical standards SAML V2.0 Profiles 4.1.3 and4.1.4.

2.2) Authentication Response
HTTP-bound authentication response messages containing SAML assertions
SHOULD be implemented in conformity with the Web Browser SSO Profile
specifications stipulated in the SAML technical standards SAML V2.0 Profiles
4.1.3 and 4.1.4.
Either the authentication response message or the authentication assertion
SHOULD be signed, and the authentication assertion SHOULD be encrypted.

2.3) Shibboleth
Shibboleth is a SAML-based software package developed and provided byInternet2 (http://internet2.edu).
Shibboleth 2.1 or newer(https://spaces.internet2.edu/display/SHIB2/Home)

Note that the Shibboleth 1.3 protocol MAY be used for the purpose of using anoverseas SP or other service.

3. Attribute Information
Attribute information is information used by each entity in deciding whether
to authenticate a user.
See the appended list of Supported Attribute Information Specifications forthe attribute information that can be used in GakuNin.

3.1) Using Attribute Information
All attribute information defined in GakuNin has a unique URI. The
attributes used by entities SHOULD to the extent possible be selected fromthe appended list of Supported Attribute Information Specifications.
In case a desired attribute is not on the list of Supported Attribute
Information Specifications, an entity SHALL be able to issue a request to the
CWSC for adding a new attribute. CWSC SHALL then decide on whether to
add the attribute to the list.
Note that attributes other than the listed ones MAY be used for services notgoing through GakuNin or limited to a private federation within an
organization.
4http://middleware.internet2.edu/dir/docs/draft-internet2-mace-dir-saml-attributes-latest.pdf

3.2) Attribute Information Trustworthiness
An IdP SHOULD guarantee the attributes of users belonging to its own
organization. It SHOULD NOT guarantee the attributes of users notbelonging to its own organization. For example, an IdP of university A
SHOULD NOT guarantee the attributes of a student belonging to university B.
If, however, an organization manages a user not belonging to it, such a user’s
attributes MAY be guaranteed by performing special attribute management toprevent illegal access to an SP.

3.3) Attribute Information Validation
An SP SHOULD perform a validation to ensure that all incoming attributeinformation has been issued by a trusted authority.

3.4) Attribute Information Levels
An SP, in providing services, SHOULD make clear to users the required
attribute information and the level of that attribute information. It is
RECOMMENDED that the levels “required,” “recommended” and “optional”
be clearly indicated along with the purpose for use of the attribute information.
An SP SHALL apply to the GakuNin Secretariat regarding attributeinformation necessary for the provided services, by using the application form
stipulated separately.
The CWSC SHALL notify each entity concerning the attribute information to
be used by each SP.

3.5) Scope
A scope MUST match the domain indicated in the EntityID. Each IdP MUST
indicate this scope in the metadata, and MUST make use of the same scope
when using a scoped attribute. An SP SHALL determine the scope of an
attribute received in an assertion by comparing it with the scope included in
IdP metadata.

4. Metadata
GakuNin uses the metadata specified below.

4.1) Metadata Specifications
The SAML V2.0 metadata specifications (see 1.3) SAML V2.0 Metadata)
SHOULD be followed.
54.2) Kinds of Metadata
The following two kinds of metadata are used in GakuNin.
 Entity metadata:
Metadata submitted to GakuNin by each entity, and indicating
information about that entity
 Federation metadata:
Metadata created by GakuNin including that of all participating entities

4.3) Submission of Entity Metadata
All organizations participating in GakuNin MUST submit entity metadata foreach of their entities to the CWSC.

4.4) Contents of Entity Metadata
In case of renewal of a server certificate that certifies the server of anorganization participating in GakuNin or changes to the organization’s
metadata, the organization MUST submit the latest version of the metadata
promptly to the CWSC.
It is RECOMMENDED that, to the extent possible, information identifying
individuals not be included in the metadata. For example, in metadata such as
the <ContactPerson> tag that requires personal information. It is
RECOMMENDED to use a group address as the e-mail address.
Note that the entity metadata submitted to the CWSC, including any personal
information included in it, will be made public on the Web (repository).
Accordingly, the administrator SHALL be assumed to have consented to thisat the time of submitting the entity metadata or at the time of application.
The CWSC SHALL use the entity metadata submitted by each organization
for the following purposes only:Validating the items included in the entity metadata

GakuNin administration, management, and operationAddition and updating of federation metadata

Distributing federation metadata to GakuNin member organizations or
making it public on the Web (repository)

Registration in a discovery service (DS), IdP, or SP

4.5) Entity Metadata <Organization> Element
An IdP SHOULD include the following information in the <Organization>
element of the submitted entity metadata.
6

Of the following information, an SP SHOULD include <OrganizationName
xml:lang=“en”> in the <Organization> element of the submitted entity
metadata and MAY include other elements.
 <OrganizationNameorganization

xml:lang=“en”>:

Official

English

name

of

the

In the case of an IdP, this MUST match the name of the IdP operatingorganization.
 <OrganizationName xml:lang=“ja”>: Official Japanese name of theorganization
In the case of an IdP, this MUST match the name of the IdP operatingorganization.
 <OrganizationDisplayName xml:lang=“en”>: Official English name of theentityIn the case of an IdP, this is the string displayed by the DS.
 <OrganizationDisplayName xml:lang=“ja”> : Official Japanese name of theentityIn the case of an IdP, this is the string displayed by the DS. If there are
multiple IdPs in the same organization, this name SHOULD be able todistinguish them.

4.6) Entity Metadata ID
When compiling federation metadata, the CWSC MAY assign an ID
distinguishing each of the submitted entity metadata, as an<EntityDescriptor> ID attribute in entity metadata.

4.7) Submission and Publishing of Federation Metadata
The CWSC MUST validate all the submitted entity metadata, then add it to
the federation metadata, validate it, and sign it, thereby creating the latest
federation metadata.
It then MUST make this metadata available to each member organization.
Federation metadata is valid for 14 days, and this MUST be indicated in thevalidUntil attribute of the <EntitiesDescriptor> element in the federation
metadata.
The
federation
metadata
group
name(=Nameattribute<EntitiesDescriptor> element) and URL for publishing are as follows.
Name=“GakuNin”
URL=“https://metadata.gakunin.nii.ac.jp/gakunin-metadata.xml”
7of4.8) Acquisition and Installation of Federation Metadata
Each member organization SHOULD obtain the federation metadatapublished by GakuNin, as in 4.7), and install it in its entities.

4.9) Updating of Federation Metadata
If an entity uses old federation metadata, not only will it be unable tointeroperate with other sites but also the entity security level may be lowered.
For this reason, it is strongly RECOMMENDED that each member
organization
regularly
updatethefederation
metadata.
The
RECOMMENDED frequency is once per day. If the update frequency is set
longer than this, it is strongly RECOMMENDED that updating take place atleast before the deadline in the federation metadata validUntil attribute.

4.10) Federation Metadata Signature Validation
Validation of signatures on federation metadata of member organizations isstrongly RECOMMENDED.

5. Discovery Service
The CWSC SHALL provide a discovery service enabling all entities in GakuNin toconfirm authentication information by the optimal means.
The URL of the discovery service provided in GakuNin is as follows:
https://ds.gakunin.nii.ac.jp/WAYF

6. Federation Support
Each entity participating in GakuNin is able to select and use at its own discretion
software supporting the protocol specified in these Standards.
Technical support is provided as necessary in GakuNin for configuring the IdP or SPof each member organization, but support SHALL NOT be offered for commercial
products.

7. Certificate Use
Certificates are used in GakuNin to ensure the trustworthiness of each entity.

7.1) Certificate for Federation Metadata Signature
The CWSC SHALL sign federation metadata with an XML signature whenpublishing and distributing the metadata.
The certificate used with this signature SHALL be a self-signed certificate
managed and administered by GakuNin. The certificate used with thesignature SHOULD also be distributed by GakuNin to each entity securely so8that each organization can validate the federation metadata signature; but thecertificate MAY be published on the Web (repository) without distributing it
directly.
The URL for publishing the certificate used with the federation metadata
signature is as follows:
Publication URL=“https://www.gakunin.jp/docs/fed/technical/signer”

7.2) Validation of a Federation Metadata Signature Certificate
An entity MUST NOT use a signature certificate having a fingerprint value
different from the value below. To confirm this, it is RECOMMENDED thateach entity use the value below to validate the signature certificate.
Fingerprint (SHA-1)=9F:8D:13:CB:E3:93:57:59:E1:81:8F:A4:26:A5:FD:60:AB:C5:01:00
The latest value is given on the following website:
https://www.gakunin.jp/docs/fed/technical/signer

7.3) Trusted Certificate Authority
An entity MUST use a certificate issued by a certificate authority trusted by
GakuNin, as listed below, as the certificate for XML digital signing and forTLS （Transport Layer Security） mutual authentication.
 UPKI open domain certificate authority
https://upki-portal.nii.ac.jp/docs/odcert (project website) A commercial certificate authority compliant with the Web Trust for CA(certification authority) and approved by the CWSC A private CA such as a university campus certificate authority that is

approved by the CWSC

7.4) What to Do When a Private Key is Compromised
If a private key used by an entity is compromised, the entity MUST
immediately notify the CWSC, revoke the associated certificates, and takealternative measures after reissuing of new certificates without delay.

7.5) Direct SOAP Connection
XML signing and TLS mutual authentication SHOULD be used when an SP
requests a direct SOAP connection,.

98. Security
In order to maintain security in GakuNin, a participating entity MUST observe thefollowing items.

8.1) User ID Management
All user information MUST be for actual users.
Each entity MUST terminate the use of a user ID without delay when thevalid term of the user ID has expired or when the user revokes the intention to
use the ID.

8.2) User ID Recycling
In case a previously used eduPersonPrincipalName or eduPersonTargetedID
is going to be used by another user, the identifier SHOULD NOT be reused
until at least 24 months have elapsed from the last use.

8.3) Assurance of the Sameness of a Claimant
An IdP MUST provide some mechanism of authentication to assure the sameness of aclaimant in the access to the protected transaction or data.

8.4) ID Use in SP
An SP providing service using an ID MUST take sufficient care to avoid
collision, etc., due to incorrect ID assignment in a database or by anassignment algorithm.

8.5) User Information Maintenance
To protect personal information , keep information up to date, and avoid therisk of data leaks, it is RECOMMENDED that an SP not store user
information other than the minimum necessary.
When it is necessary to store personal information for the sake of service
provision, this MUST be indicated to users.

8.6) User Consent
In handling attributes in an entity, in particular when sending and receiving
attributes, a function MAY be implemented for indicating the attributes to be
used and the purpose of their use and for obtaining user content.

8.7) Log Storage
It is RECOMMENDED that the access logs of a service for at least threemonths. It is RECOMMENDED that each entity stipulates the access log
storage period.
108.8) Member Organization Responsibilities
The organizations participating in GakuNin SHALL cooperate with each otherin authentication interoperation. To this end, each organization SHALL havethe duty of ensuring the trustworthiness and accuracy of the information they
send. Beyond this general obligation, however, except in the case of willful or
major negligence, they shall bear no liability for damages arising fromdeficiency in the trustworthiness or accuracy of sent information.
Note that this provision does not preclude the making of separate agreements
between member organizations regarding their responsibility for thetrustworthiness and accuracy of sent information.

9. Entities for GakuNin Administrative Use
The CWSC SHALL operate a GakuNin IdP necessary for administration of GakuNin,
and provide an attribute viewer service enabling each member organization to
conduct connection testing.

9.1) GakuNin IdP
A GakuNin IdP SHALL be operated for the use by a SP for the following
purposes:

To provide access to a SP necessary for administration of the FederationTo test a connection to a SP
Entity ID of a GakuNin IdP SHALL be the following:
Entity ID= "https://idp.gakunin.nii.ac.jp/idp/shibboleth"A GakuNin IdP SHALL hold the accounts of those who have been approved as
being necessary to administer the Federation by the CWSC. A GakuNin IdP,on exception, MAY hold a test account that is to be used by a SP for the
purpose of a connection test. Details of issuing a test account SHALL be
stipulated elsewhere.

9.2) Attribute Viewer Service
Attribute viewer service is a service that displays all attributes that can besent using the Shibboleth 2.0 protocol and Shibboleth 1.3 protocol, for viewing
by any member organization, for the sake of connection testing .
Attrviewer20:
EntityID = “https://attrviewer20.gakunin.nii.ac.jp/shibboleth-sp”
Protocol = shibboleth2.0
Attrviewer13:
11

EntityID = “https://attrviewer13.gakunin.nii.ac.jp/shibboleth-sp”
Protocol = shibboleth1.3

12

Appendix 1. GakuNin Supported Attribute Information Specifications

1. organizationName
Name
Description
Referenced
schemaName[Shib1.3]
Name[Shib2.x]
friendlyName
Value or type
Collation
sequence
Multiple values
Remarks

organizationName
Indicates the name of the organization in English
RFC4519, RFC2256 (LDAPv3)“urn:mace:dir:attribute-def:o”“urn:oid:2.5.4.10”oString (1-byte code)
caseIgnoreMatchSingleAn attribute indicating the organization name in English.
Examples: Abcdef University, National Institute ofInformatics

2. jaOrganizationName
Name
Description
Referenced
schemaName[Shib1.3]
Name[Shib2.x]
friendlyName
Value or type
Collation
sequence
Multiple values
Remarks

jaOrganizationName
Indicates the name of the organization in Japanese
GakuNin.schema
Not defined“urn:oid:1.3.6.1.4.1.32264.1.1.4”
jaoString (2-byte code)
caseIgnoreMatchSingleAn attribute newly defined for GakuNin. As a string in 2byte code, it can be used for indicating organization names inJapanese.
Examples: あいうえお大学, 国立情報学研究所

3. organizationalUnitName
Name
Description
Referenced
schemaname[Shib1.3]
name[Shib2.x]

organizationalUnitName
Indicates the English name of a unit in the organization
RFC4519, RFC2256 (LDAPv3)“urn:mace:dir:attribute-def:ou”“urn:oid:2.5.4.11”
13

friendlyName
Value or type
Collation
sequence
Multiple values
Remarksou
String (1-byte code)
caseIgnoreMatchSingleExamples: Faculty of Technology, Cyber Science Center4. jaOrganizationalUnitName
Name
Description
Referenced
schemaname[Shib1.3]
name[Shib2.x]
friendlyName
Value or type
Collation
sequence
Multiple values
Remarks

jaOrganizationalUnitName
Indicates the Japanese name of a unit in the organization
GakuNin.schema
Not defined“urn:oid:1.3.6.1.4.1.32264.1.1.5”
jaouString (2-byte code)
caseIgnoreMatchSingleAn attribute newly defined for GakuNin. As a string in 2byte code, it can be used for indicating organizational unit
names in Japanese.
Examples: 工学部, サイバーサイエンスセンター

5. eduPersonPrincipalName
Name
Description
Referenced
schemaname[Shib1.3]
name[Shib2.x]
friendlyName
Value or type
Collation
sequence
Multiple values

Remarks

eduPersonPrincipalName
Uniquely identifies an entity in GakuNin
eduPerson Object Class Specification (200806)“urn:mace:dir:attribute-def:eduPersonPrincipalName”“urn:oid:1.3.6.1.4.1.5923.1.1.1.6”
eduPersonPrincipalName[A unique and persistent identifier of each IdP]@[Scope]caseIgnoreMatchSingleA user ID assigned uniquely and persistently within
GakuNin. Uniqueness in GakuNin is guaranteed by
combining an identifier unique in the organization with ascope. The IdP sends the same value to all SPs participatingin GakuNin.
Example: t-ninsyo2009@b-univ.ac.jp

14

6. eduPersonTargetedID
Name
Description
Referenced
schemaname[Shib1.3]
name[Shib2.x]
friendlyName
Value or type
Collation
sequence
Multiple values
Remarks

eduPersonTargetedID
A pseudonym of an entity in GakuNin
eduPerson Object Class Specification (200806)“urn:mace:dir:attribute-def:eduPersonTargetedID”“urn:oid:1.3.6.1.4.1.5923.1.1.1.10”
eduPersonTargetedID<IdP entityID>!<SP entityID>![a privacy-preserving andpersistent identifier unique in each IdP and different for eachSP], 256 bytes max
caseExactMatchMultiple
A persistent user identifier unique in GakuNin and different
for each SP site is sent. The purpose is to prevent the userfrom being identified across SP sites, hence the identifier
values are required to be hashed or otherwise prevented frombeing determined.
The format consists of the <IdP entityID>, <SP entityID>, andthe hashed identifier, joined by “!”
Example:https://idp.sample.ac.jp/idp/shibboleth!https://sp.sample.ac.jp/shibboleth-sp!+Lxxl7QLnCkaKguy5xjNLRBkdDc=

7. eduPersonAffiliation
Name
Description
Referenced
schemaname[Shib1.3]
name[Shib2.x]
friendlyName
Value or type
Collation
sequence
Multiple values

Remarks

eduPersonAffiliation
Indicates the user’s occupation type, etc.
eduPerson Object Class Specification (200806)“urn:mace:dir:attribute-def:eduPersonAffiliation”“urn:oid:1.3.6.1.4.1.5923.1.1.1.1”
eduPersonAffiliation“faculty”, “staff”, “student”, “member”, none (blank)
caseIgnoreMatchMultiple
Any of five values may be used to indicate the user’s
position. In an IdP site, mapping to the actual detailed
position of the user in the organization is necessary. The
addition of other values such as “graduate” will beconsidered as necessary.
Examples: staff, member

15

8. eduPersonScopedAffiliation
Name
Description
Referenced
schemaname[Shib1.3]
name[Shib2.x]
friendlyName
Value or type
Collation
sequence
Multiple values
Remarks

eduPersonScopedAffiliation
Indicates the user’s occupation type within the organization
eduPerson Object Class Specification (200806)“urn:mace:dir:attribute-def:eduPersonScopedAffiliation”“urn:oid:1.3.6.1.4.1.5923.1.1.1.9”
eduPersonScopedAffiliation
string@scope, the string being one of the following values:“faculty”, “staff”, “student”, “member”, none (blank)
caseIgnoreMatchMultiple
This attribute defines the user’s relationship to theorganization to which he or she belongs. The values that canbe set are the same as those for eduPersonAffiliation, but ascope is appended after @.
Examples: member@nii.ac.jp, student@nii.ac.jp

9. eduPersonEntitlement
Name
Description
Referenced
schemaname[Shib1.3]
name[Shib2.x]
friendlyName
Value or type
Collation
sequence
Multiple values

Remarks

eduPersonEntitlement
Indicates qualification to use a specific application
eduPerson Object Class Specification (200712)“urn:mace:dir:attribute-def:eduPersonEntitlement”“urn:oid:1.3.6.1.4.1.5923.1.1.1.7”
eduPersonEntitlement
String (1-byte code)
caseExactMatchMultiple
This is information indicating the qualification for using aservice. For this attribute an SP site decides the string to bereceived and the IdP site uses the values decided by each SP
site. The IdP sets the value to be sent as each user’s
attribute in accord with the service use qualification decided
by the SP site.
Example: urn:mace:dir:entitlement:common-lib-terms

10. surName
Name
Description
Referenced
schemasurNameIndicates the surname in English
RFC4519, RFC2256 (LDAPv3)
16

name
[Shib1.3]
name[Shib2.x]
friendlyName
Value or type
Collation
sequence
Multiple values
Remarks“urn:mace:dir:attribute-def:sn”“urn:oid:2.5.4.4”
snString (1-byte code)
caseIgnoreMatchSingleExamples: Ninsho, Yamada

11. jaSurName
Name
Description
Referenced
schemaname[Shib1.3]
name[Shib2.x]
friendlyName
Value or type
Collation
sequence
Multiple values
Remarks

jaSurName
Indicates the surname in Japanese
GakuNin.schema
Not defined“urn:oid:1.3.6.1.4.1.32264.1.1.1”
jasnString (2-byte code)
caseIgnoreMatchSingleAn attribute newly defined for GakuNin. As a string in 2byte code, it can be used for indicating surnames inJapanese.
Examples: 認証, 山田

12. givenName
Name
Description
Referenced
schemaname[Shib1.3]
name[Shib2.x]
friendlyName
Value or type
Collation
sequence
Multiple values
Remarks

givenName
Indicates the given name in English
RFC4519, RFC2256 (LDAPv3)“urn:mace:dir:attribute-def:givenName”“urn:oid:2.5.4.42”
givenName
String (1-byte code)
caseIgnoreMatchSingleExamples: Taro, Jiro

13. jaGivenName
Name

jaGivenName
17

Description
Referenced
schemaname[Shib1.3]
name[Shib2.x]
friendlyName
Value or type
Collation
sequence
Multiple values
Remarks

Indicates the given name in Japanese
GakuNin.schema
Not defined“urn:oid:1.3.6.1.4.1.32264.1.1.2”
jaGivenName
String (2-byte code)
caseIgnoreMatchSingleAn attribute newly defined for GakuNin. As a string in 2byte code, it can be used for indicating given names inJapanese.
Examples: 太郎, 次郎

14. displayName
Name
Description
Referenced
schemaname[Shib1.3]
name[Shib2.x]
friendlyName
Value or type
Collation
sequence
Multiple values
Remarks

displayName
Indicates the name displayed in English
RFC2798 (inetOrgPerson)“urn:mace:dir:attribute-def:displayName”“urn:oid:2.16.840.1.113730.3.1.241”
displayName
String (1-byte code)
caseIgnoreMatchSingleThis is intended for use mainly as the name displayed in
English in applications.
Example: Ninsho Taro

15. jaDisplayName
Name
Description
Referenced
schemaname[Shib1.3]
name[Shib2.x]
friendlyName
Value or type
Collation
sequence

jaDisplayName
The name, etc., displayed in an application in Japanese
GakuNin.schema
Not defined“urn:oid:1.3.6.1.4.1.32264.1.1.3”
jaDisplayName
String (2-byte code)
caseIgnoreMatch
18

Multiple values
Remarks

SingleAn attribute newly defined for GakuNin.
This is intended for use mainly as the name displayed inJapanese in applications.
Examples: 認証太郎, 山田次郎

16. mailName
Description
Referenced
schemaname[Shib1.3]
name[Shib2.x]
friendlyName
Value or type
Collation
sequence
Multiple values
RemarksmailE-mail address
RFC2798 (inetOrgPerson)“urn:mace:dir:attribute-def:mail”“urn:oid:0.9.2342.19200300.100.1.3”
mailstring@domain, 256 bytes max
caseIgnoreMatchSingleThis can be used to set an e-mail address.
Example: ninsho_taro@nii.ac.jp

Reference URLs
(1) eduPerson Object Class Specification
http://middleware.internet2.edu/eduperson(2) GakuNin.schemahttps://www.gakunin.jp/docs/fed/technical/attribute#gakunin-schema19