OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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