Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Thoughts on authorization of authorized agents and removing friction in the authorized agent process #51

Open
jernst opened this issue Jun 7, 2022 · 1 comment

Comments

@jernst
Copy link

jernst commented Jun 7, 2022

What about this:

  • The consumer goes to authorizedagent.example and creates an account.
  • authorizedagent.example displays a link to coveredbusiness.example indicating that the authorized agent organization is willing/capable of performing requests on behalf of the consumer from coveredbusiness.example.
  • The consumer clicks on the link to coveredbusiness.example, which leads the browser to an OAuth-style dialog served by coveredbusiness.example.
  • First, the consumer may need to (re-)authenticate with coveredbusiness.example, just as in case of "Log in with Google" or such for OAuth.
  • Then, the dialog asks "Dear consumer, do you wish authorizedagent.example to act as your authorized agent?" This may be Yes/No or Selective/All indicating which rights the authorized agents may exercise on the consumer's behalf.
  • The dialog re-directs back to authorizedagent.example, carrying an OAuth-style token that enables the authorized agent to safely access some web service endpoint hosted by coveredbusiness.example to perform the data rights protocol. That token might last 90 days or such, so authorizedagent.example can get data from "access" even if they are slow to provide it.

This flow appears -- to me, at least :-) --

  • to authenticate the consumer with respect to coveredbusiness.example, so no abusive boyfriend scenario and just as secure as, say, having to re-authenticate to download your Facebook data directly from their site;
  • to authenticate the authorizedagent.example with respect to coveredbusiness.example -- it may require OAuth-style pre-registration to avoid fly-by-night pretend authorized agent the consumer was tricked into using;
  • to prove to coveredbusiness.example that the consumer indeed wanted to appoint authorizedagent.example as their authorized agent with respect to coveredbusiness.example;
  • to enable authorizedagent.example to safely invoke any/all features of the data rights protocol on behalf of the consumer, as the token that is wielded is specific to that consumer;
  • does not need complicated paperwork, affidavits and powers of attorney and all of that.

This just occurred to me. What am missing, why won't it work?

@jernst
Copy link
Author

jernst commented Jun 7, 2022

P.S. If this works, it would also be a great time and money saver for everybody involved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant