FAL2 - Account Resolution

[dhs-BI]

Section 3.7.2 of SP800-63C rev4 documents the requirements for account resolution which NIST defines as:

If the RP has access to existing information about a set of subscribers, and this information is not associated with a federated identifier, the RP performs a process known as account resolution to determine which set of subscriber information to associate with a new RP subscriber account.

These requirements are captured in #71. Should IPSIE eliminate the requirements in this section for purposes of SL1?

chair hat off
Account resolution within IPSIE should only be valid for JIT-provisioned accounts. How this is performed for JIT-provisioned accounts is out of scope for IPSIE, as is JIT provisioning. However, IPSIE should provide non-normative guidance in the profile at SL1 to guide implementers to a reliable process.
chair hat on

[deansaxe]

Does the WG have any feedback on this issue? I'll plan to discuss this in the upcoming agenda for June 17.

[dickhardt]

Account resolution within IPSIE should only be valid for JIT-provisioned accounts. How this is performed for JIT-provisioned accounts is out of scope for IPSIE, as is JIT provisioning. However, IPSIE should provide non-normative guidance in the profile at SL1 to guide implementers to a reliable process.

@deansaxe this sentence is confusing. Identity Lifecycle is clearly in scope for ISPSIE. Perhaps this is not an SL1 issue but a IL issue?

[deansaxe]

I understand the confusion, it arises because JIT provisioning is a thing that happens in SL*, but the resolution of those JIT provisioned accounts happens in IL*. Perhaps since this crosses the IL/SL boundary, the guidance should be written in the common requirements doc?

[dickhardt]

I think SL* should refer to IL* for JIT as JIT is not session lifecycle.

But this sentence is confusing -- is JIT out of scope? I would not think it would be.

How this is performed for JIT-provisioned accounts is out of scope for IPSIE, as is JIT provisioning.

[deansaxe]

JIT is only out of scope to the extent that IPSIE is not defining how to JIT provision a user using a federation protocol. In the levels we call this out

IPSIE Identity Lifecycle Level IL1 - User and Profile Synchronization
IPSIE Lifecycle Level P1 requires the Identity Service to synchonize with the Application the users that have access and their profile data. The Application SHALL NOT independently create, update, or delete users or the provided profile data. While an Application may also support support Just In Time (JIT) for account creation using claims in an SSO token, JIT support is NOT a requirement of IPSIE.

I agree that JIT is provisioning and it would seem to be captured under the IL* levels. But since JIT provisioning happens through the federation protocol and any claims passed to the app, that's why I made the statement above that it's part of the SL* levels. That may not make good sense! Perhaps we need to reconsider how we think about JIT provisioning in this framing.

Ultimately, the IL* levels need to consider the account resolution to establish control over these JITed identities at the application.

I hope this helps reduce confusion. Happy to discuss this on a call if needed.

[dickhardt]

I had forgotten that we had decided tht JIT was out of scope for IL* -- now your comment makes more sense!

It does seem to me that we should reopen that discussion to take into consideration account resolution.

From what I have heard, the identity service may acquire the identifier that an RP has for an account and then use that RP identifier in future interactions with the RP so that the RP is not required to add a foreign key to their DB. If I understand it correctly, this is effectively part of how SCIM works.

Karl and I have been talking about how to add this to OpenID Provider Commands.

[deansaxe]

Let's queue this up for discussion on the July 1 call.

[deansaxe]

Discussed on July 1, 2025 call, Dick and Karl will develop this work for the AB Connect group.

[ttripp]

SCIM uses something called externalID:

id
A unique identifier for a SCIM resource as defined by the service
provider. Each representation of the resource MUST include a
non-empty "id" value. This identifier MUST be unique across the
SCIM service provider's entire set of resources. It MUST be a
stable, non-reassignable identifier that does not change when the
same resource is returned in subsequent requests. The value of
the "id" attribute is always issued by the service provider and
MUST NOT be specified by the client. The string "bulkId" is a
reserved keyword and MUST NOT be used within any unique identifier
value. The attribute characteristics are "caseExact" as "true", a
mutability of "readOnly", and a "returned" characteristic of
"always". See Section 9 for additional considerations regarding
privacy.

externalId
A String that is an identifier for the resource as defined by the
provisioning client. The "externalId" may simplify identification
of a resource between the provisioning client and the service
provider by allowing the client to use a filter to locate the
resource with an identifier from the provisioning domain,
obviating the need to store a local mapping between the
provisioning domain's identifier of the resource and the
identifier used by the service provider. Each resource MAY
include a non-empty "externalId" value. The value of the
"externalId" attribute is always issued by the provisioning client
and MUST NOT be specified by the service provider. The service
provider MUST always interpret the externalId as scoped to the
provisioning domain. While the server does not enforce
uniqueness, it is assumed that the value's uniqueness is
controlled by the client setting the value. See Section 9 for
additional considerations regarding privacy. This attribute has
"caseExact" as "true" and a mutability of "readWrite". This
attribute is OPTIONAL.

SCIM defines attributes such as "id", "externalId", and SCIM resource
URIs, which cause new PII to be generated; this information is
important to the way that the SCIM protocol identifies and locates
resources. Where possible, it is suggested that service providers
take the following remediations:

o Where possible, assign and bind identifiers to specific tenants
and/or clients. When multiple tenants are able to reference the
same resource, they should do so via separate identifiers (id or
externalId). This ensures that separate domains linked to the
same information cannot perform identifier correlation.

o In the case of "externalId", if multiple values are supported, use
access control to restrict access to the client domain that
assigned the "externalId" value.