william wrote:
> 1) off the top of your head, can you think of any obstacles that
> might turn up if a saml 1.1 implementation is tailored to use a
> similar approach as what you describe in
> draft-cantor-saml-sso-delegation-01.pdf for saml 2.0?
There are many. SAML 1.1 is unable to support the technical approaches I
chose, and I have no plans to address that. Lacking a proper subject
confirmation schema, encryption support, limitations of the browser
profiles, it's just not reasonable and I don't intend to try it.
> 2) what are the likely next steps (time lines?) re the oasis
> life-cycle of the draft?
It has no OASIS life cycle. I cannot emphasize this enough. This draft
has nothing to do with OASIS or the SAML TC, it is a personal document
submitted to the project I work on (thus the filename). I will be
updating the document to reflect this.
So far, one small piece of it (profiling assertions) has produced some
interest, and there's a knock-off of it circulating on the official TC
list. I don't know whether there will be interest in advancing that. As
for the rest, I have no idea, but I doubt it. The second half of it I
expect to drop entirely, or morph into something more directly related
to Liberty.
I'd note that there's nothing in this draft you can't already do with
Liberty ID-WSF, and it supports other token types as well as SAML. The
point of this document was partly to provoke comment in my community
about whether something new is even needed.
I'll leave as an exercise for the reader to ask about the viability of
"web services" if nobody can figure out how to do stuff this basic with
all the specs out there. I think that's a telling problem.
-- Scott
