Use-case: When establishing web federation with customers we allow them to either use their salesforce username ( enforced to be globally unique ) or a federationid ( enforced to be unique to that particular customer/tenant ) as the subject of their SAML assertion. Since our SAML ACS is global for all customers, as is our OAuth token endpoint, when federationid is being used we need an additional piece of data to disabiguate the customer...essentially namespacing the federationid. On our ACS endpoint, we accept a parameter. For this use-case on our token endpoint we'll use client_id. The alternative us we use some other proprietary parameter to identify what org the client belongs to.
This is optional for us, and depends on an individual customer configuration. We will not be issuing refresh tokens. Clients will need to get/mint a new one-time-use saml bearer assertion if they want a new access token I'm a believer that devs will have to reference other docs and specs for the assertion flow. Perhaps making this language stronger would help? -cmort On Wednesday, July 7, 2010, Brian Eaton <bea...@google.com> wrote: > On Wed, Jul 7, 2010 at 4:51 PM, Chuck Mortimore > <cmortim...@salesforce.com> wrote: >> This thread forced a great deal on internal discussion today, and we >> actually do have some more immediate use-cases where we'll require >> client_id with the assertion flow >> >> I support leaving it as optional > > Can you describe the additional use cases? > > And do they require refresh tokens as well? > > I'm really worried about jamming multiple use cases into a single > profile, and then being surprised when: > a) that profile is suboptimal for all of the use cases > b) developers are hugely confused by it > > Cheers, > Brian > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
