Introduce host and AM

(epic)

As an authorizing user...

I want to tell each of my hosts which AM I want it to use...

so that I can control the selective sharing of resources at a variety of my hosts from one place.

UX

1.0

User can choose an arbitrary AM dynamically (optional), or can select among whichever preconfigured AMs the host finds acceptable.

Introduce host and AM

Discover AM metadata

As a host...

I want to discover an AM's UMA endpoints dynamically...

so that I can begin offering resource protection services to my user using whatever AM they prefer.

Protocol

1.0

Host uses AM address to construct and dereference a hostmeta address. AM hostmeta contains sufficient UMA endpoint data to get started.

Core spec step 1

Introduce host and AM

Obtain user authorization for host-AM introduction

As a host...

I want to obtain my user's consent to use their chosen AM for resource protection...

so that I can interact with the AM securely on behalf of my user in offering this protection.

Protocol

1.0

Get client credentials as host (story)

Host gets host access token and optional refresh token from AM through user authorization using the OAuth 2.0 web server profile.

Core spec step 1

Authenticate to AM as a client

(epic)

As an AM...

I want to securely distinguish each host and requester...

so that I can track their interactions with me, and enable my authorizing user to track such interactions, over time.

Protocol

1.0

AM can keep a record of which host or requester has approached it in each instance.

Dyn reg spec

Authenticate to AM as a client

Issue client credentials

As an AM...

I want to assign unique OAuth client IDs and optional secrets to each host and requester...

so that I can uniquely and securely distinguish individual hosts and requesters when they approach me on behalf of any of their respective users.

Protocol

1.0

Host or requester either statically acquires credentials (out of band), or dynamically acquires them from an AM endpoint meant for this purpose.

Dyn reg spec

Authenticate to AM as a client

Require client identification and authentication

As an AM...

I want to securely identify and authenticate hosts and requesters that approach me for an access token...

so that I can track interactions with them accurately.

Security

1.0

Host or requester presents client ID and optional secret to AM when requesting an access token. Host or requester does this only over a protected channel such as SSL.

Core spec step 1 (host), step 2 (requester)

Authenticate to AM as a client

Avoid client impersonation

As a host or requester...

I want to protect the client secret given to me by an AM...

so that no other entity can impersonate me in interacting with that AM.

Security

1.0

Host or requester protects client secret at rest (out of band). Host or requester requests tokens from the AM only over a protected channel such as SSL.

Core spec step 1 (host), step 2 (requester)

Authenticate to AM as a client

Get client credentials as requester

As an AM...

I want to acquire OAuth client credentials at an AM...

so that I can authenticate myself uniquely to the AM in future when representing any of the requesting parties using me.

Protocol

1.0

Requester either statically acquires credentials (out of band), or dynamically acquires them from an AM endpoint meant for this purpose.

Dyn reg spec

Protect resources

As an authorizing user...

I want to choose a resource residing at a host for scoped protection (selective sharing)...

so that I can ensure the resource is shared only with authorized parties and I can track authorizations from a single "hub".

Protocol

1.0

Introduce host and AM (epic)

User can select desired resource, scoping, operative policy, and any requesting-side constraints. User can observe authorization episodes.

Protect resources

Register resources and available scopes

As a host...

I want to convey to an AM that my user wants to protect (selectively share) one or more particular resources and what scopes of action are available with those resources...

so that the user can set up policies that govern access authorization over those resources.

Protocol

1.0

Host registers resource and available scope details. AM retains a correct representation of these details.

Protect resources

Request registration of resources and available scopes

As an AM...

I want to request resource registration details from a host directly...

so that any changes the user has made to resources at the host since the last time they visited the AM will be automatically picked up for policy mapping here.

Protocol

Pending

User changes to resources (such as deletion of resources or addition of new resources intended to be protected) performed solely by interaction with the host are reflected in AM's representation of which resources at that host are protected with which policies. AM can automatically attach policies to resources that did not exist when user originally directed AM to attach policies to related resources at the same host.

Do we want to solve for this flow?

Protect resources

Attach a policy to several resources at multiple hosts

As a user...

I want to protect (selectively share) several scoped resources under the same policy regime...

so that I can unify my management and monitoring of access authorization of all of the resources as a set.

UX

1.0

AM associates chosen policy with multiple resources. Access authorization to any of the resources is granted to the same set of requesting parties under the same conditions.

Protect resources

Change policy

As a user...

I want to modify the policy, required claims, and/or scopes that apply to a protected resource...

so that ensure access to the resource is exactly as broad or narrow as I wish.

UX

1.0

(@@scope-related story?)

AM changes the criteria for issuing access and refresh tokens as soon as the policy is changed. AM invalidates all existing refresh tokens and requires requesters to re-qualify. (@@correct? what about scope upgrades etc.?)

(@@need a corresponding protocol-oriented story)

Protect resources

Stop access to resources

As an authorizing user...

I want to stop further access to one or more of my resources...

so that I can remediate access problems, protect resources that suddenly become sensitive, or choose to become a more private person.

UX

1.0

(@@scope-related story?)

AM invalidates all existing refresh tokens. (@@correct? enough?)

(@@need a corresponding protocol-oriented story)

–

Extract promises

As an authorizing user...

I want to associate required promises with a policy applying to a scoped resource...

so that I can extract enforceable promises from requesting parties regarding their access to that resource.

UX

User can set up one or more promises as required claims associated with a policy that gets associated with a resource.

Require promissory claims

As an AM...

I want to require promissory claims to be conveyed by a requester from a requesting party...

so that I can authorize access only for requesting parties that meet my authorizing user's requirement for promises.

Protocol

1.0

AM generates only the claims-required messages that match the user's policy instructions and correctly assesses the status (sufficient or insufficient) of any claims returned in response.

–

Authenticate to AM

As an authorizing user...

I want to authenticate uniquely to my AM...

so that only I can use my account at the AM.

UX

The correct user can access their own account. Other users can't access that user's account.

–

Obtain fraudulent access

As a malicious requester...

I want to fraudulently obtain an access token meant for a legitimate requester and use it at a host...

so that I can gain access to a protected resource to which I do not have rightful access authorization.

Security

1.0

Requester to which an access token has been issued is correlated with requester which uses that access token so that a different requester can't successfully use it.