Delegated Authentication Use Case
Title: Delegated Authentication
This use case should be considered as a work-in-progress, and must still be evaluated within the financial services community for issues such as liability, regulatory concerns, and business value. This use case is being posted to the wiki to obtain greater exposure within the IDESG community, and to encourage comments from the community regarding technical, standards, privacy, and usability issues that appear to be relevant.
Use Case Description:
This Use Case describes an individual user granting account access to another trusted user.
Use Case Category:
Trust/Assurance, Authentication, Interoperability, Privacy
Contributor: John MacTaggart
Use Case Details
Actors:
- Individual Users
- delegated users
- Relying parties/Service providers
Goals:
As an individual user of a relying party’s service, I would like to authorize another trusted user to access my information within specified limits to simplify my sharing of information and delegation of certain activities.
This privilege must be granted for a limited period of time, with specified access constraints (what functions, what data, what privileges (e.g. read only, update…) and can be revoked at any time.
Assumptions:
1.The relying party supports delegated access.
2.Both the delegating user and the delegated user have trusted credentials within the ecosystem.
3.The delegating party can provide the relying party with account information of the approved delegated user.
Requirements:
Ref: NIST IR 7817 A Credential Reliability and Revocation Model for Federated Identities The delegating user cannot grant access above their existing privileges.
Process Flow:
1.The delegating user authenticates to the relying party with the level authentication required by the relying party.
2.The delegating user requests to manage a delegation relation with another user
3.The user specifies the user they want to grant/revoke access
4.The user establishes a delegated user relationship creating an association between the two user accounts.
5.The user specifies what group(s) of information the delegated user will have access.
6.The user specifies what level of access the delegated user will have within each group (read-only, update, delete, create new…)
7.The user specifies the time period the relationship is valid for (hours, days, or date range)
8.The user reviews their selection and sends confirmation to the delegated user selected.
9.The delegated user accesses the relying party
10.The relying party recognizes the account has privileges to access another account.
11.The relying party makes that data and those features available to the delegated user.
Success Scenario:
The delegated user can access delegating user's specified information at the relying party.
Error Conditions:
1. Either the delegated or delegating User does not have the credentials required by the relying party.
2. Relying party does not allow delegated access.
3. Delegated user attempts to access the account outside the date range specified by the delegating party.
4. Delegated user attempts to perform a function not specified by the delegating party
=== Relationships ===
- Extended by:
- Extension of:
=== References and Citations ===