auEduPerson Schema Schema Derived from: - eduPerson - person [RFC 4517, RFC 4519] - organizationalPerson [RFC 4517, RFC 4519] - inetOrgPerson [RFC 2798] - schac - auEduPerson-specific See (Sep-09): uPerson_attribute_vocabulary_v pdf?version=1 uPerson_attribute_vocabulary_v pdf?version=1 REFEDS: 21-Oct-09 1 Alex Reid, AAF & AARNet
auEduPerson Schema Standard Vocabulary: auEduPersonAffiliation auEduPerson auEduPersonLegalName auEduPerson auEduPersonSharedTokenauEduPerson eduPersonAffiliation eduPerson eduPersonAssurance eduPerson cn person eduPersonPrimaryAffiliation eduPerson eduPersonPrincipalName eduPerson eduPersonScopedAffiliation eduPerson eduPersonTargetedID eduPerson givenName inetOrgPerson mail inetOrgPerson mobile inetOrgPerson o inetOrgPerson postalAddress organizationalPerson preferredLanguage inetOrgPerson schacGenderschac schacPersonalTitle schac schacPersonalUniqueCode schac schacUserPresenceID schac sn person telephoneNumber person userCertificate inetOrgPerson userSMIMECertificate inetOrgPerson REFEDS: 21-Oct-09 2 Alex Reid, AAF & AARNet
auEduPerson Schema Levels of Assurance Attributes Guided by: 1.NeAF: Australian National e-Authentication Framework 2.Liberty Alliance: Identity Assurance Framework v1.1 3.NIST: SP800 63V1_0_2 NIST chosen to align with, as it is the most widely used. However, it is not as definitive as desired, so reference is made to the LA Framework (which has more useful detail, but is subject to review at present). NeAF is still at a formative stage (but provides useful guidance on undertaking a risk assessment analysis). NeAF and LA/Kantara will be kept under review. Two dimensions of LoA are defined: - Identity (or Registration) LoA: levels 1 to 4: eduPersonAssurance - Authentication LoA: levels 1 to 4: SAML AuthenticationMethod REFEDS: 21-Oct-09 3 Alex Reid, AAF & AARNet
auEduPerson Schema eduPersonAssurance (Identity or Registration LoA): 1= no identity proofing (but some assurance that this is the same person) 2= possession of some government-issued identity documents 3= detailed verification of valid government-issued picture Id required 4= in-person verification against government-issued picture Id SAML AuthenticationMethod (Authentication LoA): 1= simple passwords 2= password verified through a secure authentication protocol 3= 2-factor authentication through a cryptographic protocol 4= as for 3 but only hard cryptographic tokens allowed NOTE: the above summaries are very much simplified – see Schema document or LA Framework for details (especially as they relate to the difference between in-person & remote identity verification). REFEDS: 21-Oct-09 4 Alex Reid, AAF & AARNet
REFEDS: 21-Oct-09Alex Reid, AAF & AARNet5 THIS SLIDE INTENTIONALLY LEFT BLANK
Federation Operator CPS Purpose: Establish rules for SAML operation. = SAML Metadata Signing Policy & Aggregation Practice Statement Framework. [cf the way RFC3647 Internet X.509 Public Key Infrastructure Certificate Policy & Certificate Practices Framework is used to manifest trustworthiness in a PKI Federation]. Process: a. Establish small group & set up mailing list, group pages; b. Small group develop draft; c. Submit to REFEDS, ECAM, MACE, TF-EMC2 for comment? d. Small group incorporate feedback; e. Submit to IETF for eventual endorsement? REFEDS: 21-Oct-09 6 Alex Reid, AAF & AARNet
Federation Operator CPS Participants: - Rodney McDuff - Andrew Cormack - Victoriano Giralt - Scott Rea (Director of the HE Bridge Certificate Authority (HEBCA) Operating Authority Dartmouth, USA) - Leif Johansson. Corresponding member: Milan Sova. Lurkers: Licia Florio & Alex Reid. Progress: - Members agreed; - Mailing List & Wiki set up; see - Rodney prepared a very preliminary draft; - Scott preparing a fleshing-out of the headings taken from RFC3647; - Andrew to be asked to flesh out policy/legal/audit & Leif the dynamic metadata components. REFEDS: 21-Oct-09 7 Alex Reid, AAF & AARNet
Federation Operator CPS Proposed 8 Sections to the Document: 1.Audit (Security & Compliance) 2.ID Proofing 3.Certificate Issuance 4.Certificate Maintenance 5.Personnel (Trusted Roles) 6.Physical & Logical Protection of Hardware 7.Certificate Status & Repository 8.Miscellaneous [derived from RFC3647, so may vary as fleshed out] REFEDS: 21-Oct-09 8 Alex Reid, AAF & AARNet