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?
What about this:
authorizedagent.exampleand creates an account.authorizedagent.exampledisplays a link tocoveredbusiness.exampleindicating that the authorized agent organization is willing/capable of performing requests on behalf of the consumer fromcoveredbusiness.example.coveredbusiness.example, which leads the browser to an OAuth-style dialog served bycoveredbusiness.example.coveredbusiness.example, just as in case of "Log in with Google" or such for OAuth.authorizedagent.exampleto 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.authorizedagent.example, carrying an OAuth-style token that enables the authorized agent to safely access some web service endpoint hosted bycoveredbusiness.exampleto perform the data rights protocol. That token might last 90 days or such, soauthorizedagent.examplecan get data from "access" even if they are slow to provide it.This flow appears -- to me, at least :-) --
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;authorizedagent.examplewith respect tocoveredbusiness.example-- it may require OAuth-style pre-registration to avoid fly-by-night pretend authorized agent the consumer was tricked into using;coveredbusiness.examplethat the consumer indeed wanted to appointauthorizedagent.exampleas their authorized agent with respect tocoveredbusiness.example;authorizedagent.exampleto 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;This just occurred to me. What am missing, why won't it work?