Re: [OAUTH-WG] [scim] Simple Federation Deployment

There may be some similar concerns on our side. Lets talk more this week. Phil > On Apr 5, 2016, at 19:25, Hardt, Dick wrote: > > I’m talking about removing manual steps in what happens today where > configuring a SaaS app at an IdP (such as Google, Azure, Ping, Octa)

Re: [OAUTH-WG] [scim] Simple Federation Deployment

Is the idp the center of all things for these users? Usually you have a provisioning system that coordinates state and uses things like scim connectors to do this. Another approach from today would be to pass a scim event to the remote provider which then decides what needs to be done to

Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-resource-indicators-01.txt

At this point we are not considering changing the vague nature of scopes. A scope might still grant permission at the API level or finer grained. With things like the FIRE health record API there are standard scopes so I am assuming that if the client wants scope x, y ,z for health provider A &

Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-resource-indicators-01.txt

Hi Brian, I assume resource server ids or URIs to be a names namespace for scope values or that scope values are be bound to certain resource servers. It seems you have less coupling in mind? Best regards, Torsten. Sent by MailWise – See your emails as clean, short chats.

Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-resource-indicators-01.txt

Sorry for the slow response, Torsten, I was on vacation last week with my family. The omission of scope values in the example requests wasn't really intentional so much as just an initial desire to have a minimal amount of stuff in the examples. Adding a scope parameter to the example