[Openid-specs-ab] Issue #1359: Allow for alternative AuthZ flows (openid/connect)

[Thomas Bellebaum]

New issue 1359: Allow for alternative AuthZ flows
https://bitbucket.org/openid/connect/issues/1359/allow-for-alternative-authz-flows

Thomas Bellebaum:

Aggregated Claims may serve as attestation of claims to a generic class of identities. These identities may be users that are capable of following an OIDC Authorization flow, but they may also add identities to e.g. devices registered as clients to the IA.  
  
Therefore, we should clearly separate the following two phases and their purposes:  

* **Setup Phase** Establishing the IA-known identity \(e.g. a legal entity\) on behalf of which claims are issued, as well as ensuring consent of that entity.

* **Delivery Phase** Binding aggregated claims to a \(possibly purpose-bound, freshly generated\) IdA-chosen identity \(e.g. a DID\).

‌

This approach has the advantage that we do not necessarily rely on the OIDC Authorization flow for the setup phase. Devices wishing to have their claims attested by an IA may use e.g. the `client_credentials` grant type to gain an access token at the token endpoint and may then use this token at the claims endpoint.