2.1.   Registration of the OP/SIOP as a client to the Claims Provider

In the aggregated claims model, the OP/SIOP acts just as a client to the Claims Provider (CP). This means that the OP/SIOP has to register themselves as a client to the CP as an AS.

In principle, simple dynamic client registration should do.

2.2.   Linking the CP account and OP/SIOP account

The CP must be aware of the mapping between the user's account at the CP and the OP/SIOP.

The CP needs to return the linkage in the returned JWT. It can be either:

• returned as a sub
• returned as a link object.

The sub way introduces a special semantics on it. Perhaps better to have a link object such as:

"equiv_sub":{
    "iss":"OP/SIOP issuer identifier",
    "sub":"subject identifier at the OP/SIOP"
}

2.3.   Requesting Access and Refresh Tokens

Requesting Access and Refresh Tokens follows the RFC6750 pretty much. However, to make the response include the sub that is related to the Aggregated Claims response, a parameter that indicates the user may need to be added here.

2.4.   Requesting only needed claims in the Resouce Request to the Claims Provider

To streamline the U/X, the intermediate OP as a client to the CP may want to obtain blanket access to the CP and constrain what is being returned to it depending on the context, effectively making it act as the authorization server for the CP for the user.

This means there needs to be a way to constrain what is being returned from the CP at the resource request time.

3.1.   Key rollover

SIOP should be able to roll the key over.

Use-cases include:

• When SIOP proactively changes the keys
• When SIOP thinks that the key has been compromised
• Key recovery: When the user loses SIOP's keys.

3.2.   Key recovery

Need for redundancy.

3.3.   Use of the same identity on multiple devices

Cross-device syncing or something similar needed. Kim mentioned that his implementation works cross-device. It was also mentioned that hardware-based keys may pose problems in this regard.

3.4.   Avoid calling-home problem

If the RP tries to find the validity of the signing key at the CP, CP may well be able to find out who went to the RP by using per-user kid etc. (CP as the adversary case.)

Onion-network may not work in this case either. A shared database in which a node can not observe the access to another node may work -- e.g. blockchain-based key validity checking.

3.5.   Registering IdP with Claims Provider

This is the same issue as "Registration of the OP/SIOP as a client to the Claims Provider" above.

3.6.   Need for long-term signatures, usable even after issuer goes out of business

Possible storage of key sequences via BlockChain or other methods

3.7.   Publishing revoked keys

Can possibly be determined without revealing the key