This IG says of SMART: "This guide is also intended to be compatible and harmonious with client and server use of versions 1 or 2 of the HL7 SMART App Launch IG.". It's true that it tries to be compatible whenever possible, but there are clear incompatibilities, so please clarify when and how the two mechanisms may be combined.

It seems that the most basic way for both UDAP and SMART to coexist is to isolate them completely at the API level: the server uses distinct endpoints for everything, the client chooses one or the other, by going to .well-known/udap or .well-known/smart-configuration, and sticks with that choice for the whole OAuth workflow (from discovery through resource access). Both client and server can take advantage of code reuse internally as possible, but the APIs are distinct.

In Discovery, the note in section 2.2 alludes to this: "Having different metadata endpoints permits servers to return different metadata values for different workflows.", but doesn't require it.

Beyond that, I see two possible dimensions for UDAP and SMART to coexist:

• Compatible at the transaction level (e.g. a transaction like token request/response can satisfy both SMART and UDAP requirements)
• Can combine in a workflow (e.g. get a client ID using UDAP registration and use it in SMART workflows)

Which work? Which make sense? Which should not be attempted?

In Registration, SMART doesn't profile RFC 7591 much, and UDAP does. Could a single registration suffice as both a UDAP and a SMART registration? How would the client satisfy "the client SHALL register the public key that the client will use to authenticate itself...SHALL be conveyed to the FHIR authorization server in a JSON Web Key (JWK) structure presented within a JWK Set"? The JOSE header for UDAP is specified differently.

In Authorization, authorization request, maybe they are compatible?

In Authorization, token request, SMART profiles the client auth JWT differently from UDAP: they support different algorithms and different JOSE headers.