Yes - this is intended to be a simplified parallel to web sso profile. We also intend to ship a straight adaptation of websso, as do others I believe
For both of these, We intend to enforce one time use; I suspect that type of state maintenance will get argued against by those running the large scale consumer systems...it's manageable for us given how our Multi-tenancy is setup. I could see relaxing this to a should if people feel strongly. It would be good to see some arguments/use-cases along with the objections I would also like to see other profiles, such as a holder of key profile. This is a good starting point for what our customers need /request, but we intend to expand profiles as customers and the industry evolve - cmort On Jul 27, 2010, at 9:49 AM, Brian Campbell <bcampb...@pingidentity.com> wrote: > On Thu, Jul 22, 2010 at 3:39 PM, Torsten Lodderstedt > <tors...@lodderstedt.net> wrote: >> Sounds like you defining a profile of the OAuth assertion flow for using >> SAML assertions complying to the SAML "Web Browser SSO Profile". I think you >> should state that somewhere. There will probably be other assertion flow >> profiles for other SAML assertion "dialects". > > It's not *exactly* like the the Web SSO Profile but similar in most > respects. I'll work in some language about that intent in the next > draft. > > >>>> Your I-D states: >>>> "The authorization server MUST ensure that bearer assertions are >>>> not replayed, by maintaining the set of used ID values for the >>>> length of time for which the assertion would be considered valid >>>> based on the NotOnOrAfter attribute in the >>>> <SubjectConfirmationData>." >>>> >>>> Why do you want to force a one-time usage for SAML assertions? >>>> This is to restrictive, in my opinion. >>>> >>> >>> This is also a carryover from web SSO via the POST binding. I was >>> actually leaning towards not including this language but a couple >>> early reviews were interesting in having it in there. My co-author on >>> this draft, Mr. Chuck Mortimore, was one of those folks so maybe he >>> could provide more insight into his reasoning there. Chuck? >>> >>> >>>> >>>> Any issuing authority could enforce such a >>>> policy by using the "OneTimeUse" element. >>>> >>> >>> Personally, I've always found the spec language around OneTimeUse to >>> be confusing and somewhat ambiguous. Maybe I'm wrong but take a look >>> at "2.5.1.5 Element<OneTimeUse>" and the treatment of OneTimeUse in >>> "2.5.1 Element<Conditions>" of saml-core-2.0-os. There are parts of >>> that language that do suggest OneTimeUse is intended to indicate that >>> some replay check is required but other parts seem to say something >>> entirely different. I don't believe that OneTimeUse is widely used >>> or supported. >>> >> >> We don't use it, too :-) > > :) > Anyone else have thoughts on the "not replayed" clause in here? I'm > on the fence about it, as I said. Chuck, I know your busy conference > hopping but if you get a chance, can you describe again why you > thought this was important? > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
