extend the definition of first party to include strictly defined trust frameworks

[Sakurann]

using this draft in the context of EUDIW ecosystem would solve some problems in the following scenarios:

• scenario 1: using eID tap (physical card) to authenticate the user when issuing a PID (government issued digital credential). eID card talks directly to the eID server, but the tap needs to be mediated by the wallet/client since it requires NFC. So there is no need for a browser during authorization request. German EUDIW Architecture project has an implementation of this and it is not very oauth compliant nor interoperable since a response with authorization code is not an authorization response. eID server and the issuer of a PID is the government or is authorized by the government to read the data from eID.
• scenario 2: Present PID to authenticate the user when issuing a QEAA (any other credential, can be mobile driving license). Some use-cases do not want to show the user the browser and want to go straight to the PID presentation screen after the QEAA issuance request (but some use-cases might need a browser - redirect_to_web error would be very useful). Both wallet that stores PID and the QEAA issuer needs to be certified/registered with the government/European Commission. Issuer of QEAA needs to be authorized to receive PID.

Had a discussion with the editors and they were reluctantly willing to enable the usage of the draft in a situation where a tightly defined trust framework can be considered equivalent to a first party scenario:

• Issuer/AS can identify the "first-partiness" of the wallet and is sure that wallet knows what to do in that flow
• Issuer/AS is authorized to get that user data from the wallet
• security properties are also clearly defined
• all this is tightly defined in a profile of first party app spec

cc @danielfett @cre8