[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: SAML configuration/interoperability woes
David, I am not suggesting negotiation of configuration parameters but to not be bound to hard-coded "pull" URLs. Such URLs are likely to break too frequently. I.e. the a destination site should IMO not need to know anything but the PKC of the source site. That is at least what a coming e-commerce initiative that I am working with has as a built-in requirement. Orginally my intention was to use SAML but I currently feel less tempted due to several URL- related problems. For example if the destination URL (which typically points to a catalog entrance page) changes, the *user* will be left with a HTTP 404. In the our current draft the source *server* will get this information first-hand which is much better for error-handling and correction if we are talking *really* wide deployment. Anders ----- Original Message ----- From: "Orchard, David" <dorchard@jamcracker.com> To: "Anders Rundgren" <anders.rundgren@telia.com>; "OASIS SAML" <security-services@lists.oasis-open.org>; "Mishra, Prateek" <pmishra@netegrity.com> Sent: Wednesday, July 11, 2001 18:12 Subject: RE: SAML configuration/interoperability woes I don't think plug-and-play is a requirement for SAML. I think our requirement is run-time interoperability, but not setup/configuration. Certainly we want to make configuration easy as possible, but negotiation of configuration parameters leads us to the bootstrap problem. We can be successful with SAML 1.0 by ensuring run-time interop, IMHO Dave > -----Original Message----- > From: Anders Rundgren [mailto:anders.rundgren@telia.com] > Sent: Wednesday, July 11, 2001 4:42 AM > To: OASIS SAML; Mishra, Prateek > Subject: SAML configuration/interoperability woes > > > Continuing from Browser Artifact question > > When I look on the F2F-binding paper, paragraph 3.1.2 I get some > feelings that this is not designed for plug-and-play. Specifics: > > - The sample PartnerID is supposed to be communicated out-of-band > - There is no place to store the assertion "pull" URL > - Are the type-code to be registered? > > Artifacts introduce new problems that IMHO have not yet gotten > suitable generic solutions. > > Minor detail: B64 encoding means Base64? If so I would add > that this in turn must be URL-encoded as well to not get problems > with "=". > > rgds > Anders R > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC