Concerns about Examples A5 and A7 (User-Transferred Authorization Data Pattern)

[marcopernpruner]

We came across Examples A5 and A7, which refer to the "User-Transferred Authorization Data Pattern" described in Section 2.3. However, we are not sure whether these examples are in line with the description of the flow. In particular, our main concern is related to the identification of the Initiating Device and Authorization Device, as these entities cannot be uniquely assigned to any of the two devices involved (personal computer and mobile device).

Considering Example A5, the employee “is logged-in on the personal computer where they initiate the process”, so we would expect the personal computer to be the Initiating Device. However, this cannot be true as:

• the QR code should be displayed on the personal computer, not on the mobile device;
• the final authorization is granted to the personal computer (which is, indeed, already connected to the network) instead of the mobile device.

On the other hand, the personal computer should be considered as the Authorization Device, as it is already connected to the network, thus it is responsible for displaying the QR code and granting the mobile device access to the network it is connected to. However, this cannot be true as the process should be started on the personal computer, not on the mobile device.

Therefore, it seems that the personal computer plays both roles sometimes during the process: it initiates the process (as an Initiating Device) and displays the QR code (as an Authorizing Device), while the mobile device cannot be really identified in the flow.

As a side note, if QR codes can be used as authorization data in this flow (step D), this should be made explicit in the description of the flow (as already done in Section 2.1 when referring to the "User-Transferred Session Data Pattern", at step C).

CC @giadas

[PieterKas]

On second reading, I agree that these examples on't match the pattern. In addition, although it is a cross-device flow, it is different in that it is more about a session transfer/authorization transfer. Options to consider:

1. These are the equivalent to regular phishing and social engineering attacks and are out of scope for this spec (e.g. the attacks does not result in the user authenticating, but rather in the artefact being moved)
2. We can broaden the definition of cross device flows to include these session transfer scenarios and create a new flow, even though this is not strictly a cross-device consent attack (i.e. introduce a new cross-device attack that is not about consent, but more generally about transferring QR codes and other artefacts).

@danielfett what kind of attacks are you seeing in the decentralised identity space, and should these be covered here as well?

[PieterKas]

Discussed with Daniel. conclusion is to treat Cross-Device Session transfer as a superset of cross device consent phishing. We will prepare aa PR and take it to the OAuth mailing list before merging.

[danielfett]

Nonwithstanding the inclusion of the CDST, I think we should reconsider Examples A5, A7 and A8. They all pertain to the User-Transferred Authorization Data Pattern, but for the first two, the Initiating Device is really the Authorization Device, as pointed out by Marco.

I think we should consider calling the Initiating Device the Consuming Device instead: In all three flows, it is the device that at the end of the day gets access to the resource. In A8, this is also the device initiating the flow, but in A5 and A7 it is not. I think it is fine to keep the description of UTADP as it is, but say that in a variant, the initiation is done by the Authorization Device.

[danielfett]

Note from call today: The second case shown above is essentially session transfer.