...
| Anchor | ||||
|---|---|---|---|---|
|
...
Accepted)
Submitted by: Michael Hanson
...
- Does this scenario require an explicit model of delegation enforced by the AM, so that BizService can't hand off an access token to anybody they want?
Use Case: BizTools Impersonates BizService (
...
Accepted)
Today, app-hosting relationships commonly involve sharing of private keys (covered by service-level agreements), and concomitant "impersonation" of the company by the outsourced service. This use case would seem to be transparent to the user (for example, if the user is given a real-time opportunity to consent to access when BizTools/BizService attempts it, the request will appear to come from BizService) and to the UMA protocol.
Use Case: BizTools Provides Its Own Network Endpoint (
...
Rejected)
If BizTools approaches the resource not by impersonating BizService but in its own right (on BizService's behalf), true delegation would somehow have to come into the protocol picture. The goal would be to avoid creating an "omnipotent token" that allows the proximate Requester (BizTools) to use the token for access on the behalf of other parties. As discussed on 2009-10-08, we are inclined to reject this use case.