Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add asymmetrical connectivity use cases #54

Merged
merged 2 commits into from
Dec 9, 2019
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 13 additions & 0 deletions UseCases.md
Original file line number Diff line number Diff line change
Expand Up @@ -51,3 +51,16 @@
- Blogs wants to read data about Alice’s interests
- Alice does not want Blogs to get data about her interests
- Blogs continually asks Alice to grant it access to her interests and Alice is annoyed with the incessant asking
- Alice uses or is developing http://localhost:8080 to view her photos
- Alice's Identity Provider can't reach Alice's `localhost:8080`
- Alice's Pod can't reach Alice's `localhost:8080`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one doesn't seem to be as much of a use case as it is something to look out for. Would you like to phrase this as Alice should be able to test things out in a localhost setting?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's not just testing or developing. deployment to localhost should be a legitimate scenario. i'll rephrase in more generic terms (not "to view her photos" but "any app").

- Alice uses https://coolcode.int.enterprise.example to edit code stored in Customer Bob's Pod
- *CoolCode* is deployed behind Enterprise.Example's company firewall
- *CoolCode* is proprietary to Enterprise.Example; or
- *CoolCode* is a commercial product that is deployed on-premises at Enterprise.Example's datacenter
- Alice's Identity Provider can't reach https://coolcode.int.enterprise.example
- Customer Bob's Pod can't reach https://coolcode.int.enterprise.example
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same thing here. This should be phrased as a use case with a goal that Alice has to accomplish and not just a setup.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the intent here was to illustrate by example a possible and legitimate configuration of actors that should work, which is how all the other use cases work. i can rephrase this to more explicitly call out the intent to cover the configuration, and then give the example.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note too that this use case already includes an implicit goal similar to all the other use cases: "Alice uses X to edit code stored in Customer Bob's Pod"

- Alice uses https://photoOrganizer.example to organize photos on her company's private storage server https://storage.private.enterprise.example
- `storage.private.enterprise.example`'s TLS certificate is signed by Enterprise.Example's private Certificate Authority
- Alice's web browser is configured to trust Enterprise.Example's private Certificate Authority
- `storage.private.enterprise.example` is reachable from the public Internet, so Alice's Identity Provider and *photoOrganizer* could reach it; however, neither is configured to trust Enterprise.Example's private Certificate Authority