Support bot-backed Actionable Message cards in Outlook (approve/deny as the signed-in user) - parity with Teams

[sarahcritchley]

Summary

Enable Adaptive Card / Actionable Message cards delivered through Outlook to invoke an agent on behalf of the signed-in Outlook user, so approve/deny (and similar) action
buttons work end-to-end the same way they do in Teams and other chat clients today.

The card should carry the identity of the signed-in Outlook user when an action is taken,
so the agent can authorize the approve/deny decision against the right user. This flow is
reliable in chat clients (Teams), but the equivalent path in Outlook does not
work cleanly.

Problem / Background

• Chat clients (e.g. Teams) support cards that trigger bot actions carrying the user's
  identity. Approve/Deny resolves cleanly through the agent
• In Outlook, sending the same actionable card and wiring an approve/deny action to a
  agent does not work cleanly. There is no clean equivalent to the working Teams path, and the provider/agent registration flow for Outlook Actionable Messages is currently broken.

Registration flow is broken today

• The link surfaced by ABS lands on an experience with no botID registration support - you cannot register a provider for the bot/agent.
• Docs point to the right URL but the NEW button does not support adding an agent/bot
• The only working path is a manually constructed URL:
  https://outlook.cloud.microsoft/actionablemessage/oam/new?token=<token> which is not discoverable
• After registration, requests are returning a 501

Desired Behavior

1. An Actionable Message / Adaptive Card sent via Outlook can invoke a registered bot when
   the user clicks an action (Approve / Deny / etc.).
2. The action call carries the signed-in Outlook user's identity/token so the agent can
   attribute and authorize the decision to the correct user - matching Teams behavior.
3. Approve/Deny resolves through the bot and reflects state back in the card, with parity
   to the chat-client experience.
4. The provider/agent registration flow works from a single discoverable entry point:
   • ABS emits a correct base link (or aka.ms short link) into the OAM registration
     experience, with the token passed through automatically.
   • The NEW button supports adding/registering a agent.
   • Post-registration action calls no longer return 501.

[tracyboehrer]

There is a POC of this in https://github.com/microsoft/Agents-for-net/tree/users/tracyboehrer/ac-attributes-oauth. See the OutlookUAM sample.

While this also works in Teams, I could not determine how to handle consent. But this flow isn't needed as it might have been in BF SDK. Teams Adaptive Cards can use the existing Token Service flow and SSO without using this.

[tracyboehrer]

This was resolved in microsoft/Agents-for-net#897 for DotNet. This is the minimal handling of Adaptive Cards OAuth (close to the way BF SDK dealt with it). It does NOT include an OAuth Handler to make it conform to our way of dealing with OAuth (GetTurnToken, etc...). But that could be a next step if we want.

[MattB-msft]

Resolving this issue now as we have shipped a point fix for this and this use case seems to be semi limited right now.