...
If the Requester can identify itself (and the requesting party standing behind it) to the Authorizing User's satisfaction, it can allow for various the user can set policies and make decisions to flow, resulting in the Requester gaining access.An AM could make use of Requester identification in two ways: by comparing its that result in appropriate Requesters gaining access.
For example, the Kantara InfoSharing WG's car-buying scenario suggests that car buyer Sally might want to let her husband and a friend (individual people with online identities) see her collected research on new-car options, or to authorize her car's manufacturer (a corporation) to access personal data required for her membership in its frequent-road-trip club. And the calendar-sharing scenario and personal loan scenario include allowing access to a specific Requester application, such as the website for a credit card or mortgage company (acting on the instructions of and on behalf of the selfsame person as the authorizing user).
If an AM can find out the unique identity of a Requester/requesting party, it can make use of it in two main ways:
- Compare the identity to some policy with which it has been
...
- pre-configured in order to make a decision
- Convey the identity to the Authorizing User in an out-of-band request for real-time consent to access (based on prior user instructions to do
...
- this)
...
This table summarizes specific motivations for use cases exploiting both of these choices.
...
Use Case: Pre-Authorization with Self-Asserted Label (Pending)
"Anyone can gain access if they introduce themselves."
This use case is likely not to involve any sort of sophisticated matching of pre-authorization policy to a particular string that any Requester can just make up. Rather, it is likely to involve a policy that freely gives access to relatively non-sensitive resources as long as the audit log entries can consistently use some sort of Requester-chosen label. This is marginally more interesting than merely recording IP addresses, assuming the Requester chooses to use a label that is intuitive and accurate on some level.
Use Case: Pre-Authorization with Identity from Trusted/Whitelisted Issuer (Pending)
In the case where the Requester is able to wield an identity that is verified by a particular issuer (such as Twitter or particular OpenID providers), or one of a whitelist of such issuers, the Authorizing User may choose to set up policies that pre-authorize access based on this greater level of assurance. It could be powerful, for example, "Let (anyone, this identity) from (this issuer, one of these issuers) gain access."
This might apply in the case of Sally the car buyer, and granting access to her husband and friend. She could specify that Requesters acting on behalf of her husband's Google identifier or her friend's Twitter handle always get access to certain protected resources. If she can be sure that Google or Twitter has vouched for the requesting user on whose behalf the Requester is making its access request, this is a greater level of assurance that warrants pre-authorization.
Likewise, it could be powerful to pre-authorize Amazon.com (acting on behalf of the person who also happens to be the Authorizing User) to get access to one's shipping address or vendor-neutral wishlist, or to pre-authorize a set of social networking applications to get (read and/or write) access to one's social graph or geolocation information at other applications already in the authorized circle (as in the distributed services scenario).
The Authorizing User could also, if identities of friends and family at sites such as Google and Twitter are known, create "ACLs" (access control lists) that enumerate the allowed parties per resource or host. (Note that design principle DP9 protects Authorizing User privacy at the expense of parties standing behind the Requester; some authorization policy depends on knowing the identity of those who approach the resource looking for access.)
...