# SIOP Proposed Adaptations > Note: Not yet listed - portable identifier as subject type. Would prefer someone more enthusiastic about DID-SIOP describe that 1. **Provider collectives** A collective would be a group of OPs with a common entity identifier and authorization endpoint. The identifier is expected to be resolvable to get metadata on common supported functionality. 2. **Subject authority and confirmation** The goal would be to in define the concept of subject authority (e.g. is this claims provider or OP making authoritative statements about the subject) and confirmation (how do I determine if the subject or an authorized holder is the party I'm communicating with). These may be intertwined, as a non-authoritative source or intermediary may require stronger proof-based confirmation vs traditional bearer methods used in OAuth/OIDC. 3. **Claims aggregation and OIDC4VP** Defines a way to acquire and present claims about subjects when your provider is not authoritative for that subject. Might or might not be separate specifications 4. **`sub_jwk` as subject type** Indicate the ability to cryptographically generate self-authoritative, pairwise subject identifiers. I suspect this was the correct way to do this, but may cause challenges with backward compatibility with SIOP. 5. **Automatic RP registration** Allow a RP to authoritatively state its supported configuration via a resolvable identifier. This might use OpenID federation's feature wholesale. We would need to decide if we describe and map traditional SIOP behavior (redirect_uri as client_id with metadata) to a documented registration type. 6. **Trust frameworks via OIDC-Fed** Define metadata formats for various verifier, holder software, issuer capabilities as well as supported token formats and supported schema, such that they are usable to define participants as well as potentially limit usage to certified participants. 7. **OP attestations** Provide the way to indicate the provenance (origin) of a provider within a collective, to understand if it has been certified to operate within a trust framework 8. **OIDC VP profile** Similar to other conformance profiles such as the basic profile and implicit profile, a minimal set of supported functionality and credential schema in order to self-certify for general use. Might be recycled by others for trust framework audit and certification.