[WG-UMA] Questions about discovery and claims required.

[Holodnik, Tom]

Folks,

Here's a scenario that might help illustrate some issues that our meetings last week motivated (at least they mootivated me).

- How does UMA handle highly restrictive information, where requirements come from the user and from other agencies?
- How does UMA handle dynamic configurations between Hosts and AMs?
- How does the Requester know what they need to provide to the AM in order to properly assert their credentials (and satisfy requirements from the 1st question)?

These seem like uniquely UMA concerns that don't yet seem to be present in OAuth 1.0a or WRAP (at least as I read them).

There seem to be cases where the Host needs to know whether the AM supports specific kinds of access policies and Opt-In procedures, the AM needs to discover aspects of the Host, and the Requester needs to discover what they need to deliver to properly assert their identity.

Consider IRS Rule 7216, that specifies the requirements that tax preparers should meet in order to access tax return information for any purpose other than filing taxes.

Currently, there are products available to meet the use case of providing data for access to financial aid, but consider how it might be conducted in UMA:

Alice's daughter is starting college at UCLA in the fall. The financial aid department needs a copy (or an extract) of Alice's tax return to determine eligibility for financial aid. UMA might be applied like this (skipping lots of error handling and HTTP-level details):

1. Alice tells Taxmonkey.com that access to her return should be managed by copmonkey.com (or some other UMA Access Manager). There's presumably one and only one Access Manager (AM) for her tax data.

Alice goes through an IRS-sanctioned, 7216-compliant Opt-In protocol to enable access for qualifying services, such as financial aid and loan issuers. Alice also tells Bob (a Financial Aid administrator at UCLA) where to get her tax return.

2. When Alice configures her Taxmonkey.com preferences like this, Taxmonkey.com discovers the URLs to drive the mechanics of the UMA protocol with her chosen Access Manager (AM).

[@@TBS: More granular description needs to be prepared that explains how Taxmonkey.com discovers interfaces at copmonkey.com; what it needs to discover, whether it copmonkey.com supports the kinds of controls that are required for the types of resources hosted at Taxmonkey.com, etc. Also, the manner in which Alice passes introductions to Bob needs to be described.]

3. Bob, the Financial Aid administrator at UCLA, connects to Taxmonkey.com, and Taxmonkey.com redirects him to copmonkey.com.

4. Bob presents a collection of information to copmonkey.com that allows the AM to verify that the Requester is a party that complies with the policies and preferences expressed by Alice.

[@@TBS: This is where a "Claims Required" dialog needs to be presented. A process that verifies that Bob is really Bob, and that he's operating as a Financial Aid Administrator at UCLA, and that the "root" of these claims can be verified by copmonkey.com. If Bob asserts identity purely through an email exchange or via OpenID, it's not yet clear that it will satisfy requirements from the IRS, or that a reasonable person would want to allow access to financially sensitive information based on claims or attributes provided in OpenID. The ID-Assurance WG would seem to have something to say here; there may be a need for Level of Assurance N, where N is appropriate to the resources being served.]

5. If Bob meets the access criteria by providing claims appropriate for the resources, the AM issues a token, and Bob passes this in each request to Taxmonkey.com to retrieve data from Alice's tax return.

6. Taxmonkey.com may, at its discretion, call back to the AM to "punch the ticket" that Bob presented before granting access. This might be to further validate Bob's access, to verify Bob's identity, to track access requests at the AM, and/or to prevent Bob from accessing this data more than once.

[@@ The discovery process needs to provide the location of the Back-Channel interfaces at the AM. ]

7. Sometime later, Alice is able to login to the AM and review the kinds of access that Bob has and make changes if appropriate. She may decide that after she gets the financial aid package that Bob no longer needs access, and then turn his access off. If several other entities have access to Alice's tax data, she can review that access and adjust it at any time.

[@@ This isn't really a protocol function, but it seems like a functional requirement for the AM. From one AM to the next, the presentation ought to be clear enough that Mom can use it constructively and not be misled. ]

There could be a few discovery processes in this case:

- The Host determines that the AM operates in a manner consistent with the handling of tax information (maybe that it will require several forms of identification and authentication) before granting access to the resources

- The AM discovers the methods or resources on the Host that require highest protection and policy controls. It might be that for most daa (name, address, phone, etc.) the access policy is no more than a baseline set. However, when the Requester attempts to access my salary, list of bank accounts,and my taxpayer ID number, a higher degree of policy enforcement is required.

- The Requester, Bob, needs to know what claims he needs to provide in order to conduct the work that Alice specified. It may be that these are Alice's requirements and preferences, or they may be implicitly described in the requirements from the IRS and other tax agencies.

I've assumed that copmonkey.com knows that Bob will access resources classified at Level "High" and that anyone presenting a token certified at this level can access resources classified at Level "Low" - copmonkey.com arranges things to avoid situations where Bob will have to come back for another round of access negotiation to work with taxmonkey.com.

Some portions of this flow seem to suggest that there are some AMs that are best suited for certain purposes. It might be that the AM for hData operates with terms, support, and

Apects of this reminded me of George Fletcher's ideas and ideas from the hData scenario, but I've not yet done the transformation on those ideas into this case. I'll read them through and apply them if I can.

Does this scenario really illustrate the "extras" that UMA may need to provide beyond what OAuth provides? Or is there some way to achieve this within OAuth that I missed? Ideally, all problems should have simple solutions and we don't need to invent.

I hope this is helpful!
-tom



_______________________________________________
WG-UMA mailing list
WG-...@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma

[Paul C. Bryan]

On Wed, 2010-04-07 at 11:32 -0700, Holodnik, Tom wrote:

Folks,

Here's a scenario that might help illustrate some issues that our meetings last week motivated (at least they mootivated me).

- How does UMA handle highly restrictive information, where requirements come from the user and from other agencies?
- How does UMA handle dynamic configurations between Hosts and AMs?
- How does the Requester know what they need to provide to the AM in order to properly assert their credentials (and satisfy requirements from the 1st question)?

These seem like uniquely UMA concerns that don't yet seem to be present in OAuth 1.0a or WRAP (at least as I read them).

There seem to be cases where the Host needs to know whether the AM supports specific kinds of access policies and Opt-In procedures, the AM needs to discover aspects of the Host, and the Requester needs to discover what they need to deliver to properly assert their identity.

Do you see such needs as being primary or secondary to the UMA protocol? The problem I see with trying to inject such capabilities into the core protocol is that prerequisites a host may have of AM or vice-versa seems like it can be arbitrarily complex. I think it's possible that UMA could be used recursively to solve some of these types of usage, but at a high—likely prohibitive—cost, though the alternatives of adding plumbing to allow host and AM to discover aspects of each other will come at significant complexity costs nevertheless.

<slight type="nostalgic" severity="slight">

>From day one (in ProtectServe), we knew there was a missing piece to be filled: allowing AM to determine the resources at host to be protected. I think to pass the mom-test, AM needs to display a list of resources (and/or "groups" and/or "scopes") at host to specify in a policy. In the calendar example, mom wants to share her social events, but medical appointments are off-limits. URLs are not going to cut it. Mom doesn't know what a URL is. She knows what calendars she has, or the types she setup for tagging appointments. If this is mom's photo albums, listing albums, or even displaying thumbnails of pictures are called for.

Such distinctions are host/resource specific and there's no chance AM could know about these ahead of time, nor render every possible type of resource. AM somehow needs to rely on host to participate in scoping resources for access control policies. The simple way out I saw (for implementors) was to allow mom to at host to tag resources as a part of a particular group, name that group, then specify that group at AM. More intuitive, but more costly protocol-wise: during editing of a policy at AM, AM defers UI to host to allow individual resources to be selected (e.g. individual photos in the album), then magically express them such that they can be included in the policy—either individually as resources or as to some new agreed-to scope between host and AM.

</slight>

I think the best chance (or at least the potentially least-complex way) for meeting the needs listed in Tom's email would be to be associated with this type of discovery which will probably be necessary in one form or another.  

Consider IRS Rule 7216, that specifies the requirements that tax preparers should meet in order to access tax return information for any purpose other than filing taxes.

Currently, there are products available to meet the use case of providing data for access to financial aid, but consider how it might be conducted in UMA:

Alice's daughter is starting college at UCLA in the fall. The financial aid department needs a copy (or an extract) of Alice's tax return to determine eligibility for financial aid. UMA might be applied like this (skipping lots of error handling and HTTP-level details):

1. Alice tells Taxmonkey.com that access to her return should be managed by copmonkey.com (or some other UMA Access Manager). There's presumably one and only one Access Manager (AM) for her tax data.

Alice goes through an IRS-sanctioned, 7216-compliant Opt-In protocol to enable access for qualifying services, such as financial aid and loan issuers. Alice also tells Bob (a Financial Aid administrator at UCLA) where to get her tax return.

2. When Alice configures her Taxmonkey.com preferences like this, Taxmonkey.com discovers the URLs to drive the mechanics of the UMA protocol with her chosen Access Manager (AM).

[@@TBS: More granular description needs to be prepared that explains how Taxmonkey.com discovers interfaces at copmonkey.com; what it needs to discover, whether it copmonkey.com supports the kinds of controls that are required for the types of resources hosted at Taxmonkey.com, etc. Also, the manner in which Alice passes introductions to Bob needs to be described.]

3. Bob, the Financial Aid administrator at UCLA, connects to Taxmonkey.com, and Taxmonkey.com redirects him to copmonkey.com.

4. Bob presents a collection of information to copmonkey.com that allows the AM to verify that the Requester is a party that complies with the policies and preferences expressed by Alice.

[@@TBS: This is where a "Claims Required" dialog needs to be presented.  A process that verifies that Bob is really Bob, and that he's operating as a Financial Aid Administrator at UCLA, and that the "root" of these claims can be verified by copmonkey.com.  If Bob asserts identity purely through an email exchange or via OpenID, it's not yet clear that it will satisfy requirements from the IRS, or that a reasonable person would want to allow access to financially sensitive information based on claims or attributes provided in OpenID.  The ID-Assurance WG would seem to have something to say here; there may be a need for Level of Assurance N, where N is appropriate to the resources being served.]

I'm generally resistant to N-based assurances, but I'll try to keep an open mind. I think it would be far more useful where assurance level can be expressed in some form of liability—be it financial or otherwise—because this gives a meaningful consequence to getting assurance wrong and serves to keep issuers honest. I presume a "larger-N-based" assurance level will have significant consequences, but an abstract ordinal number seems to imply the lack the decentralization that to me would be necessary for a market of useful issuers—issuing claims on a wide range of topics—to emerge. You may say I'm a dreamer... Hmm...

<deviation type="poetic" severity="excruciating">

Imagine there's no Centralization
It's straightforward if you calculate
No abstract ordinal-based assurance
A fully distributed web-scale slate...

</deviation>

For those who just cringed at my Dataesque poetry, if it's any consolation, I am not a poet, I should not be a poet, and I wrote it on-the-fly. I will now hold a contest for the best word that rhymes with calculate.

5. If Bob meets the access criteria by providing claims appropriate for the resources, the AM issues a token, and Bob passes this in each request to Taxmonkey.com to retrieve data from Alice's tax return.

6. Taxmonkey.com may, at its discretion, call back to the AM to "punch the ticket" that Bob presented before granting access. This might be to further validate Bob's access, to verify Bob's identity, to track access requests at the AM, and/or to prevent Bob from accessing this data more than once.

Okay, this is where I get in trouble. Now, host wants to verify Bob's identity, which isn't a problem in itself. The problem is now it wants to use AM to do it. Suddenly, host is going beyond trusting user to decide what AM, and now needs to trust information—beyond simply authorizations—that AM supplies it with. If we need to go down this road, I think I need to know more concretely what host would need of AM, and what consequences AM will need to accept should it fail to provide this.

I think the preventing-access-more-than-once issue is thorny (due to the nature of HTTP's semantics), and probably best left for host to handle itself. 

[@@ The discovery process needs to provide the location of the Back-Channel interfaces at the AM. ]

7. Sometime later, Alice is able to login to the AM and review the kinds of access that Bob has and make changes if appropriate. She may decide that after she gets the financial aid package that Bob no longer needs access, and then turn his access off. If several other entities have access to Alice's tax data, she can review that access and adjust it at any time.

[@@ This isn't really a protocol function, but it seems like a functional requirement for the AM. From one AM to the next, the presentation ought to be clear enough that Mom can use it constructively and not be misled. ]

Mom definitely appreciates you mentioning her. Please continue to keep her in mind.

There could be a few discovery processes in this case:

- The Host determines that the AM operates in a manner consistent with the handling of tax information (maybe that it will require several forms of identification and authentication) before granting access to the resources

- The AM discovers the methods or resources on the Host that require highest protection and policy controls. It might be that for most daa (name, address, phone, etc.) the access policy is no more than a baseline set. However, when the Requester attempts to access my salary, list of bank accounts,and my taxpayer ID number, a higher degree of policy enforcement is required.

- The Requester, Bob, needs to know what claims he needs to provide in order to conduct the work that Alice specified. It may be that these are Alice's requirements and preferences, or they may be implicitly described in the requirements from the IRS and other tax agencies.

I've assumed that copmonkey.com knows that Bob will access resources classified at Level "High" and that anyone presenting a token certified at this level can access resources classified at Level "Low" - copmonkey.com arranges things to avoid situations where Bob will have to come back for another round of access negotiation to work with taxmonkey.com.

I think this raises the MAC-vs-DAC issues we've discussed before. Does AM really need to know the classification of data sensitivity at host? It sounds like host has its own policies it needs to enforce, be it statutory or based on risk analysis. Would it not be more appropriate for host to simply enforce its own internal policies rather than outsource them to the user-managed AM?

Some portions of this flow seem to suggest that there are some AMs that are best suited for certain purposes. It might be that the AM for hData operates with terms, support, and

Apects of this reminded me of George Fletcher's ideas and ideas from the hData scenario, but I've not yet done the transformation on those ideas into this case. I'll read them through and apply them if I can.

Does this scenario really illustrate the "extras" that UMA may need to provide beyond what OAuth provides? Or is there some way to achieve this within OAuth that I missed?  Ideally, all problems should have simple solutions and we don't need to invent.

I don't see how OAuth 1/2 or WRAP could solve many of these problems themselves. 

I hope this is helpful!

It is! Thanks for starting this thread.

Paul

[Eve Maler]

Belatedly following up with written comments on this message from Tom... This is very relevant to the WG discussion we had today.

On 7 Apr 2010, at 11:32 AM, Holodnik, Tom wrote:

> Folks,
>
> Here's a scenario that might help illustrate some issues that our meetings last week motivated (at least they mootivated me).
>
> - How does UMA handle highly restrictive information, where requirements come from the user and from other agencies?
> - How does UMA handle dynamic configurations between Hosts and AMs?
> - How does the Requester know what they need to provide to the AM in order to properly assert their credentials (and satisfy requirements from the 1st question)?
>
> These seem like uniquely UMA concerns that don't yet seem to be present in OAuth 1.0a or WRAP (at least as I read them).

Agree.

>
> There seem to be cases where the Host needs to know whether the AM supports specific kinds of access policies and Opt-In procedures, the AM needs to discover aspects of the Host, and the Requester needs to discover what they need to deliver to properly assert their identity.

Agree with this too.

In some highly domain-specific circumstances, full dynamicism may not make sense. E.g., given the regulations around tax information, would it be better for all these parties to (a) whitelist each other or use other methods of credentialing each other ahead of time, and (b) statically define and conform to profiles that say exactly what flows and claims should be used? I've been guessing that the hData scenarios might require this, for example.

>
> Consider IRS Rule 7216, that specifies the requirements that tax preparers should meet in order to access tax return information for any purpose other than filing taxes.
>
> Currently, there are products available to meet the use case of providing data for access to financial aid, but consider how it might be conducted in UMA:
>
> Alice's daughter is starting college at UCLA in the fall. The financial aid department needs a copy (or an extract) of Alice's tax return to determine eligibility for financial aid. UMA might be applied like this (skipping lots of error handling and HTTP-level details):
>
> 1. Alice tells Taxmonkey.com that access to her return should be managed by copmonkey.com (or some other UMA Access Manager). There's presumably one and only one Access Manager (AM) for her tax data.
>
> Alice goes through an IRS-sanctioned, 7216-compliant Opt-In protocol to enable access for qualifying services, such as financial aid and loan issuers. Alice also tells Bob (a Financial Aid administrator at UCLA) where to get her tax return.
>
> 2. When Alice configures her Taxmonkey.com preferences like this, Taxmonkey.com discovers the URLs to drive the mechanics of the UMA protocol with her chosen Access Manager (AM).
>
> [@@TBS: More granular description needs to be prepared that explains how Taxmonkey.com discovers interfaces at copmonkey.com; what it needs to discover, whether it copmonkey.com supports the kinds of controls that are required for the types of resources hosted at Taxmonkey.com, etc. Also, the manner in which Alice passes introductions to Bob needs to be described.]

If our step 1 (AM/host introduction) involves not just an embedded OAuth instance but an embedded UMA instance, then CopMonkey could demand claims of TaxMonkey! :-) However, we don't currently have any way of doing the reverse, that is, letting TaxMonkey dynamically satisfy its questions about CopMonkey's qualifications. Is whitelisting in this direction sufficient for now, do you think?

>
> 3. Bob, the Financial Aid administrator at UCLA, connects to Taxmonkey.com, and Taxmonkey.com redirects him to copmonkey.com.
>
> 4. Bob presents a collection of information to copmonkey.com that allows the AM to verify that the Requester is a party that complies with the policies and preferences expressed by Alice.
>
> [@@TBS: This is where a "Claims Required" dialog needs to be presented. A process that verifies that Bob is really Bob, and that he's operating as a Financial Aid Administrator at UCLA, and that the "root" of these claims can be verified by copmonkey.com. If Bob asserts identity purely through an email exchange or via OpenID, it's not yet clear that it will satisfy requirements from the IRS, or that a reasonable person would want to allow access to financially sensitive information based on claims or attributes provided in OpenID. The ID-Assurance WG would seem to have something to say here; there may be a need for Level of Assurance N, where N is appropriate to the resources being served.]

Yes. In fact, a verifiable claim about the requesting party being a certified member of a particular trust framework could aggregate a lot of useful info in a small package. Of course, today NIST 800-63 focuses only on identity assurance and not on "attribute assurance", though there are a lot of people who want the latter solved ASAP...

>
> 5. If Bob meets the access criteria by providing claims appropriate for the resources, the AM issues a token, and Bob passes this in each request to Taxmonkey.com to retrieve data from Alice's tax return.
>
> 6. Taxmonkey.com may, at its discretion, call back to the AM to "punch the ticket" that Bob presented before granting access. This might be to further validate Bob's access, to verify Bob's identity, to track access requests at the AM, and/or to prevent Bob from accessing this data more than once.
>
> [@@ The discovery process needs to provide the location of the Back-Channel interfaces at the AM. ]

Yep. You're referring to the real-time token validation notion, right? We do have a fledgling solution for discovery of the AM's token validation endpoint, but we don't yet have a fleshed-out protocol for what the host actually sends to the AM to kick off validation. There are actually lots of things those two could talk about, so homing in on the specifics of what you'd *like* them to talk about would be great.

>
> 7. Sometime later, Alice is able to login to the AM and review the kinds of access that Bob has and make changes if appropriate. She may decide that after she gets the financial aid package that Bob no longer needs access, and then turn his access off. If several other entities have access to Alice's tax data, she can review that access and adjust it at any time.
>
> [@@ This isn't really a protocol function, but it seems like a functional requirement for the AM. From one AM to the next, the presentation ought to be clear enough that Mom can use it constructively and not be misled. ]

Yep, that's correct. The technical report published at http://www.cs.ncl.ac.uk/publications/trs/papers/1196.pdf has a nice accounting of policy-setting and how it fits into the picture.

>
>
> There could be a few discovery processes in this case:
>
> - The Host determines that the AM operates in a manner consistent with the handling of tax information (maybe that it will require several forms of identification and authentication) before granting access to the resources

Right, and currently we're missing this entirely or assuming it's out of band.

>
> - The AM discovers the methods or resources on the Host that require highest protection and policy controls. It might be that for most daa (name, address, phone, etc.) the access policy is no more than a baseline set. However, when the Requester attempts to access my salary, list of bank accounts,and my taxpayer ID number, a higher degree of policy enforcement is required.

We've been assuming for simplicity that the user manages this themselves at the AM, but it would be aided by some AM/host back-channel exchange of info, e.g. the list of resources the user controls at the host... This is unspecified so far, but could be very interesting to take farther.

>
> - The Requester, Bob, needs to know what claims he needs to provide in order to conduct the work that Alice specified. It may be that these are Alice's requirements and preferences, or they may be implicitly described in the requirements from the IRS and other tax agencies.

Yes, this is where a domain-specific profile might come in, so that the claims requested aren't a complete surprise.

>
> I've assumed that copmonkey.com knows that Bob will access resources classified at Level "High" and that anyone presenting a token certified at this level can access resources classified at Level "Low" - copmonkey.com arranges things to avoid situations where Bob will have to come back for another round of access negotiation to work with taxmonkey.com.

A low vs. high sensitivity setting on individual resources is one way for an AM to go in presenting policy-setting options, but there are lots of other ways to go. This is where having the SMART implementation and Christian's prototype to play with (he suggested calling it "DUMB" :-) will help us more than guessing will.

>
> Some portions of this flow seem to suggest that there are some AMs that are best suited for certain purposes. It might be that the AM for hData operates with terms, support, and
>
> Apects of this reminded me of George Fletcher's ideas and ideas from the hData scenario, but I've not yet done the transformation on those ideas into this case. I'll read them through and apply them if I can.

I think we're on the same wavelength!

>
> Does this scenario really illustrate the "extras" that UMA may need to provide beyond what OAuth provides? Or is there some way to achieve this within OAuth that I missed? Ideally, all problems should have simple solutions and we don't need to invent.
>
> I hope this is helpful!
> -tom

Very much so! I took an action today to turn your presented flow into a scenario for the Scenarios document. If you'd like to collaborate on that (or already already most of the way there), let me know...

Eve

Eve Maler
e...@xmlgrrl.com
http://www.xmlgrrl.com/blog

_______________________________________________
WG-UMA mailing list
WG-...@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma

--
You received this message because you are subscribed to the Google Groups "Kantara Initiative User Managed Access WG" group.
To post to this group, send email to kantara-init...@googlegroups.com.
To unsubscribe from this group, send email to kantara-initiative...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/kantara-initiative-uma-wg?hl=en.