multiple (SAML) assertions also mean multiple subject statements. Are there any constraints regarding the relations among those subjects (identities)?
regards, Torsten. Am 12.08.2010 um 22:01 schrieb Brian Campbell <bcampb...@pingidentity.com>: > I generally agree more with Chuck, David and Brain E than I don't. > But I do think that someone will find a pragmatic reason for > 1 > assertion eventually and I think the proposal earlier in this thread > to allow for multiple occurrences of the assertion parameter in the > core spec will make that easier for a number of instantiations of the > assertion flow (grant type) at a later time. It adds some complexity > but I don't think a lot. And specifications or pairwise agreements > building on the assertion flow could easily constrain down to a single > assertion, if it suits the profile. > > That's the only change proposal to the core spec that's come out of > discussion around my I-D > http://www.ietf.org/id/draft-campbell-oauth-saml-00.txt (that I can > think of). I'm still not sure if it makes sense to allow for multiple > assertions in the next draft of that, but allowing for multiple > assertion params in core sure seems like a cleaner way to do it. > > Yaron's proposal for a Section 2.2 on Client Assertions is a change to > core as well (latest in that thread: > http://www.ietf.org/mail-archive/web/oauth/current/msg04154.html). > However, even though it uses the term assertion similarly, it's a > distinct issue from the SAML work. The latter is a SAML based usage > of the assertion grant type while the former I think of it more as a > means of allowing for stronger forms of client authentication than > just a client password/secret. > > I guess both could be used in a two-legged style interaction (or used > together) and maybe that's where it starts to get confusing... > > > > On Thu, Aug 12, 2010 at 1:38 PM, Brian Eaton <bea...@google.com> wrote: >> On Thu, Aug 12, 2010 at 12:36 PM, David Recordon <record...@gmail.com> wrote: >>> I've only been half following the recent assertion threads for this >>> exact reason. I don't understand how these proposals are going to be >>> used and worry about any additional complexity added to the spec. >> >> Likewise. >> _______________________________________________ >> 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
