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

Reply via email to