“SCIM” Next Steps
'Session Topic: “SCIM” Next Steps – Planning Ahead: x Domain ID Management
Tuesday 2I
Convener: Bill Mills
Notes-taker: Phil Hunt
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
Three proposed topics:
- authentication - “oauth 2.0 is more wrong than other choices”
- P2P instead of client server model
- more capabilities - per user feedback
Signaling
Bill Mills has desire to do signaling on account actions via SCIM - think shared signals. Yahoo Mail observes Eric’s mail account is compromised and is now sending Spam from multiples ip/locations. In federated scenario, how can the email provider notify the IDP of suspicious activity?
Phil brings up Tony and his lightweight authentication protocol
- a problem emerges as to who is responsible for what. Do RPs have right to tell IDPs what to do?
If so, what *should* RPs be telling IDPs if anything?
Ian suggests looking at Andrew Nash’s shared signals work
Phil. Would a token approach work where Yahoo issues session tokens for emails based on an authentication from an IDP. That way Yahoo can revoke rights for an abuser without need of alerting IDP.
However it still doesn’t solve the problem of Yahoo playing nice and informating the IDP of a suspicion about a Nigerian spammer.
Another case is Yahoo acting as IDP to Google Apps.
PubSub seems to be an interesting way to deliver these events.
Is there a liability issue in sending these messages. E.g. biz partners that separate.
We discussed a number of issues SCIM has started exploring regarding ASYNC operations: workflows, bulk requests, event notifications.
Ian raises issue about situation in which SCIM server is bombarding SCIM client. Can the client tell the server to throttle its requests? A too busy state/code in HTML?
Bill was thinking about being able to enable a server to write to a subset of a user object but he recognizes that isn’t ideal - this is a p2p approach
- he isn’t sure that pubsub model
Phil raises point he and @cmort looking at PubSubHubbub for event model
talk on token approach for mail accounts
the general case of the conversation - I need to tell you about one of your accounts and I want you to do something about it, but I cannot touch it because you own it.
Bulk and large scale transactions
Instead of bulk what about SPDY?
Authentication
We can use OAuth2 but that isn’t a requirement
Some other bearer token?
Or just have an agreement that it’s a JSON token with a specified format
should we sign the payload?
- we could a JSON signing token profile for SCIM
