...
- AI: Eve: Alice-to-Alice sharing (RO-to-self)
- In Justin's description of the "multiple parties" use case (which is generally the "UMA use case"), he says "UMA extends this to allowing the Requesting Party to be the one using the client, but it generally doesn’t collapse cleanly into the cases where the RO is the party using the client since the claims gathering endpoint and the authorization endpoint aren’t quite the same in concept."
- However, this doesn't seem right. What should happen is that RqP (that we happen to know, if we are outside the system, observing, that the policy happens to match Alice-again, is the RO) should be taken not to the authorization endpoint but to the claims interaction endpoint. We confirmed that Gluu's implementation, e.g., does it this way. If there is no policy whatsoever in place, then Alice-the-RqP's client might get, say, request_denied and Alice-the-RO might be given the opportunity to create a policy for the first time that happens to match herself.
- AI: Eve: Reach out to Justin to discuss this use case.
- AI: Eve: Proactive Alice-to-org sharing (RO-to-client developer, so to speak)
- AI: Peter: Bob is assured to a certain level that Alice is who she says she is (strong Alice-to-AS binding or "CIBA-like")
- Transactional and long-term management of sharing of preferences with service providers
...
- George
- Vlad
- Thomas
- Colin
Regrets:
- Andi
- Mike