...
Maciej demonstrated SmartPDS.appspot.com. He showed registering for/signing two things: (1) signing in the user to an authorization server during the sign-in process to the SmartPDS resource server, and (2) allowing SmartPDS to obtain a PAT during that authentication process. The first step is for the new user to register for/sign in initially to the app through the Google IdP, which generated generates an OAuth-based response coming from Google. The redirect back to the SmartPDS relying party gets intermediately redirected through a proxy, which checks before sending the user back to SmartPDS whether SmartPDS is UMA-enabled. If so, it adds a code to a URL parameter. SmartPDS it signs in the user to the SmartAM authorization server, which generates the PAT on the back end. SmartPDS can then execute a simple call to the SmartPDS Connect API (basically an enhanced OpenID Connect-based API) to obtain the PAT so that the SmartPDS RS and AS can get easily introduced. SmartPDS's knowledge of which AS to use is buried in the SmartPDS app's configuration process; it happens only to work with SmartAM. Alternatively, Patrick the user could have been asked to choose any suitable AS at the time of registration to SmartPDS.
Eve believes the "automatic PAT issuance" use case will be particularly valuable in sector-specific use cases where a trust framework/broker situation requires use of a single AS (or short list of them). Is it worth profiling this formally? Yes, seemingly so, since this isn't a vanilla OAuth flow but an OpenID Connect-enhanced one. This logic would apply identically to the AAT issuance process and the requesting party, vs. the PAT issuance process and the resource owner. Essentially, since OpenID Connect-format user data is available through the federated login to the app (which may be an RS), this data can be leveraged for efficient PAT/AAT issuance.
...