Page History

Anonymous

Providing access with no ongoing user tracking. E.g., based on ePSA or ePE only.

• Surveys
• Wireless
• Library

• Any

No

No

No

External

"Open" Affiliates

Non-business affiliates accessing "public" services

• Wikis
• Local profiles (library, public services)

• Researchers
• External Colleagues

No

No

No

External
Personal Invite

Non-business Affiliates

Individual with local permissions for "non-core business" purposes

• Facilities access
• Food services

• Summer camp attendees
• Conference attendees

Yes?

Entry, no account

Yes?

Business Invite

Ad-hoc personal affiliates

Non-business affiliates gaining access to targeted local resources

• Bill Review
• Collaboration team
• Extension  help desk

• Parents
• External Researchers
• Volunteers

No

No

No

Personal Invite

Should real-world person map be "yes?" We want to know who is accessing targeted local resources.

Business affiliates

Business affiliates with affiliation

• Business Systems
• LMSes
• Data repositories

• Contractors
• External Auditors
• Cross-enrolling students
• Guest Lecturers
• VO members
• BYOC

Yes?

Entry, no account

Yes

Business Invite

Does tracking the invitation initiator (local uid) make sense to this id use?

Inbound affiliate

Someone granted temporary access based on external credentials, but expected to migrate to (potentially more-highly vetted) internal credentials at a later point

• Email
• Applications (Emp and Student)
• File access
• Desktop access

• Job applicants
• Student applicants

Yes

Yes (but not immediately)

Transitional

Business Invite

Outbound affiliate

Someone with internal credentials, who is expected to lose access to those credentials (and replace them with an external credential)

• Email
• Transcripts
• W-2s, Paystubs
• Employment Verification

• Alumni
• Past Students
• Separated Employees
• Retirees

Yes

Yes

Yes

Self Linking
Business Invite?

Alternate factor

Using an external ID to provide privilege escalation in certain contexts

• Password Reset
• Validate sensitive operations

• Any?

Yes

Yes

???

Self Linking
Business Invite

Use Case

Generic name of the category being described

Brief Desc

Brief Description of Use Case

Service

List of examples IT services to which this Use Case would provide access

Client Relationship

Typical business customers; i.e., "who would use this service"

Real-World Person Map?

Is it important to the local services to know or validate the identity of the person in control of the external credential (as opposed to just validating the credential)?

Local IDM entry?

Would the local IDM system typically maintain an Identity record describing this individual? (May impact SP- vs IdP- centric solutions)

Yes implies an identity and credentials are locally managed.
Entry, no account implies that there would likely be an identity, but no actual credential managed in the local IDM system

Attribute Link?

Would local IT services expect to leverage attributes from the user's local (IDM-managed) Identity as part of IAM interactions? (May impact SP- vs. IdP-centric solutions)

Yes and No should be self explanatory
Transitional implies that initially the permissions may be managed by the local IDM, but eventually there's an expectation that the external credential would be retired in favor of the (eventual) local credential.

AuthZ/Registration

Describes the general mechanism used to authorize the external credential to be used for access in this use case

External = Local systems trust external IdP assertions
Personal Invite = An individual grants access to (individually managed) resources. This could be done in the context of an actual invitation service, "whitelisting" user IDs, or some other local authZ process
Business Invite = An authorized business agent grants access to (generally broader) resources. As with "Personal Invite", could be done in the context of an invitation service, "whitelisted" IDs, or other process.
Self Configuration = An individual links two accounts by some approved business mechanism (online, in person or via help desk)

Issues/Risks

Lists both technical impediments to implementing/supporting and the business risk questions ("why we might not be willing to trust these IDs") surrounding this use case.