5.3.2 RP Subscriber Accounts
All changes in this version
Title
RP Subscriber Accounts
Control
It is common practice for the RP to associate a federated login with a local account record. This record is defined as the RP subscriber account in [SP800-63C] . The RP subscriber account can contain things like access rights at the RP as well as a cache of identity attributes for the subscriber.
Each federated identifier, as described in Sec. 6.2.1 , SHALL be associated with a single RP subscriber account. The RP subscriber account SHALL NOT rely on any other identifiers within the PIV data record (e.g., card UUID or email address) for uniqueness or tracking a PIV identity account over time.
The RP MAY associate multiple federated identifiers with a single RP subscriber account to perform account binding as discussed in [SP800-63C] . The RP MAY allow access to the RP subscriber account with a locally-verified authenticator, but when such an action is taken, access to the RP is not considered PIV federation.
To minimize the amount of information sent to the RP, RPs SHOULD use just-in-time provisioning for the RP subscriber account, as defined in [SP800-63C] , when possible. To avoid data duplication and synchronization issues, the RP SHOULD minimize the amount of data stored in the RP subscriber account. Note that it is possible for an RP to associate the same set of authorizations and 970 971 972
973 974 975 976 977
978 979
980 981 982 983
984
985 986
987 988 989 990
991 992 993
994 995 attributes to two different RP subscriber accounts, depending on the needs of the RP. The means and details of doing so are outside the scope of this specification.