Solve for various "requester-to-host first" (known resource location) vs. "requester-to-AM first" (unknown resource location) flows (related to discovery)

[xmlgrrl]

As discussed in UMA telecon 2011-08-11 (http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2011-08-11):

In hData, you have to discover the EHR service providers. If a specialist needs information held by your primary-care physician, the specialist may not know the endpoint of the PCP's service yet. You need to discover the endpoint, and the patient/authorizing user also has to authorize that discovery somehow. We assume that the specialist can learn the location of the discovery service somehow, to "bootstrap" all this. This could be solved by OpenID Connect's discovery model, we think, as long as that discovery model is protectable/authorizable (through OAuth itself or through UMA?).

[In the past we've talked] about "requester-initiated" vs. "discovery-service-initiated" flows. But the use cases actually break down further:

• Requester-to-host for one resource set/scope (has been provisioned the resource location somehow, presumably knows the API for accessing it, doesn't know what's required to get access of all the types of permissions it seeks) – we have, so far, solved only for this flow.
• Requester-to-host for one/multiple resource sets with multiple scopes (has been provisioned the resource location somehow, presumably knows the API for accessing it, doesn't know what's required to get access of all the types of permissions it seeks, but wants to efficiently get multiple permissions added to its token at once)

This has been requested by Maciej M. We'd need to drill down farther on the one vs. multiple resource sets question. Implementation choices will change depending on how frequently each pattern is needed.

It's easier to solve for a single resource set with multiple scopes vs. multiple resource sets when the requester approaches the host first, since it would presumably approach with a concrete request against a particular resource.

But the host is authoritative for the protected resource sets there, so it could serve as a kind of distributed resource-set discovery service.

Or, since the AM has been told all this information by the host, the host could just refer the requester to the AM to find out possible resource sets.

But the requester is, so far, completely untrusted, so it should only learn/discover what's appropriate for it at this point. So maybe sending it to the AM for initial authorization to discover things is needed. This is what we think OpenID Connect wants to do.

• Requester-to-AM (with discovery functionality) first - We keep going in the direction of seeing the AM as needing discovery functionality!

Simple Web Discovery seems to depend on OAuth protection, but our original idea (reflected in the etherpad) was that you'd UMA-protect the discovery service, as a "host of discovery data". Would this actually simplify the OpenID Connect view of discovery services? Currently they seem to be treated specially.

The Project hData folks have experimented with both magnetic stripe cards and QR codes for allowing a patient to provision their discovery service's URL to a medical provider to bootstrap the process.

[xmlgrrl]

Early discussion from UMA telecon 2011-06-23 (http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2011-06-23):

John comments that the Simple Web Discovery protocol gives simple, unconstrained access to a discovery service; probably this wouldn't be suitable for hData. OpenID Connect gets more sophisticated, helping to give back a claim to a deserving requester by giving an access token to get into that service. Would an hData "Discovery and Authorization Service" (DAS) want to be OpenID Connect-enabled in order to get the extra layer of permission that it offers? We had sketched a potential scenario for applying UMA to hData where both potential requesters could approach the DAS to get the locations of health data, and also potential hosts could approach the DAS to try and put their own metadata into the DAS. In that latter case, it's more like an "introduction service".

[xmlgrrl]

Discussed in UMA telecon 2011-09-08: This is yet a different way there may be UMA/OpenID Connect synergy. OpenID Connect is trying to solve for some discovery use cases. UMA (e.g., the hData use case) would need a "protected" discovery service, not an open one, but otherwise we think it has very similar needs. How can aspects of the two be combined or reused for best efficiency and modularity? Keep in mind that UMA solves for third-party requesters and absent authorizing users for arbitrary protected resources, while OpenID Connect solves for present authorizing users trying to start a session and protected claims specifically.

[xmlgrrl]

See closed issue #2 for context: The requester-to-host first flow now has a solution based on OpenID Connect. The question of requester-to-AM first may be illuminated by further experience with OpenID Connect (for example, what if a person's AM is also their OpenID Connect identity provider, and can serve as a discovery service for arbitrary "claims" that could include user-generated content etc. and not just what we traditionally think of as identity claims?).

[domcat]

The nature of the Authorization Manager makes it compatible with Discovery service capabilities.
This approach optimizes the protocol, without the needs to include a further distributed component.
With this assumption, Requester-to-AM+DS first can be resolutive also for aggregated resources.

[xmlgrrl]

In WG discussions around June 2012, we put this issue aside for now, relying on the fact that we have a "naive" way to answer the need. Samplings:

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2012-05-31
http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2012-06-07
http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2012-06-14
http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2012-06-21

[xmlgrrl]

Discussion from UMA telecon 2012-12-06: Introduction: Would it be a good idea to mention Account Chooser as a non-normative suggestion in the spec for introduction? Also, should we explicitly acknowledge the possibility of "AM-initiated" introduction vs. our current assumption of "host-initiated introduction"? OpenID Connect doesn't really solve for IdP-initiated SSO; there are some security issues with getting it to work perfectly. So they're leaning towards a naive solution where the IdP makes it easy for the user to get redirected to the RP so that they can "start" from the right place. We can use that as well, for now. Whenever the security problems with true IdP-initiated SSO flows get worked out to everyone's satisfaction, we can pick up on it for AM-initiated host introduction.

[xmlgrrl]

Discussion from UMA telecon 2012-12-06: There are three kinds of discovery. IdP discovery (literally parsing out the domain of a user-entered URI) is one kind; tools like .well-known could be used. Another kind/level is AP/IdP or host/AM introduction; tools like Account Chooser could help with that. Then there's a personal discovery service a la Liberty ID-WSF's Disco service. For the discovery service, UMA's naive way of "solving" claim/resource discovery has been that the requester could construct a "known" location URI of an intermediate resource hosted at the AM, so that the requesting party could qualify in to get access to the pointer stored there, and thereafter get access to the ultimate resource. This conflates discovery and registry functions, and the request for access is also implicitly a request for knowing whether the resource exists. This is why the resource registration function of UMA is so key; enough information about the semantics of the resource has to be "registerable" in a machine-readable way to enable a requester to seek and get access to what they want.

If we were to separate out "phase 1", that's not necessarily the right line to draw to make a Disco API spec reusable for both UMA and non-UMA purposes. The key piece is the resource registration CRUD API. We think we should separate this out, and perhaps finally use the http-json-resource spec (http://tools.ietf.org/html/draft-pbryan-http-json-resource-02 -- see issue #36) as well. Should we account for the old XRD provisioning spec (http://xrdprovisioning.net/specs/1.0/wd01/xrd-provisioning-1.0-wd01.html) as well? Let's think about leveraging these two. Note that UMA-protecting a discovery resource enables the AM to obscure any PII that might be ensconced in the URI of the ultimate resource, since the requester has to "test in" to get authorization even to know whether it exists.

[xmlgrrl]

We have made some progress on this general topic by taking up #110. Thus, we'll backlog this specific issue for now, and hope to consider it fully in the V1.x timeframe.