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] | [List Home]


Subject: RE: [security-services] Interop Test question: Metadata 2.0 EndpointType question


+1

> -----Original Message-----
> From: Brian Campbell [mailto:bcampbell@pingidentity.com]
> Sent: Wednesday, September 28, 2005 2:17 PM
> To: Eric Tiffany; SAML
> Subject: RE: [security-services] Interop Test question: Metadata 2.0
> EndpointType question
> 
> IMHO, "A" is the (only) proper interpretation.  The text, "When a role
> contains an element of this type pertaining to a protocol or profile
for
> which only a single type of message (request or response) is
applicable,
> then the ResponseLocation attribute is unused" is refereeing to
> endpoints like the Assertion Consumer Service and the SSO Service
which
> would only ever receive a particular type of message (response or
> request respectively).  It makes no mention of binding - perhaps it
> should be called out that a response location for a synchronous
binding
> is nonsensical but that really should be clear.
> 
> The text below from metadata implies (I think) that ResponseLocation
is
> optional and that if it's not included, the Location should be used
for
> both request and response.
> 
> "ResponseLocation [Optional]
> Optionally specifies a different location to which response messages
> sent as part of the protocol or profile should be sent. The allowable
> syntax of this URI depends on the protocol binding."
> 
> > -----Original Message-----
> > From: Eric Tiffany [mailto:eric.tiffany@ieee-isto.org]
> > Sent: Wednesday, September 28, 2005 10:42 AM
> > To: SAML
> > Subject: [security-services] Interop Test question: Metadata 2.0
> EndpointType question
> >
> > We have a small difference of opinion I'd like to resolve.
> >
> > The EndpointType (starting line 225 of Metadata spec) provides an
> optional
> > ResponseLocation:
> >
> >     The ResponseLocation attribute is used to enable different
> endpoints
> >     to be specified for receiving request and response messages
> associated
> >     with a protocol or profile, not as a means of load-balancing or
> >     redundancy (multiple elements of this type can be included for
> this
> >     purpose). When a role contains an element of this type
pertaining
> to a
> >     protocol or profile for which only a single type of message
> (request
> >     or response) is applicable, then the ResponseLocation attribute
is
> >     unused.
> >
> > We have one implementation ("A") that is omitting the
ResponseLocation
> from
> > its metadata specification for HTTP-Redirect SLO because the
Location
> > endpoint can handle both the request and response.  Another
> implementation
> > ("B") interprets the text above to mean that the ResponseLocation
> should
> > only be omitted for the SOAP binding, and is requiring that the
> > ResponseLocation be specified in metadata for other bindings.
> >
> > I tend to agree with "A", but wondered if anyone (besides "B") sees
a
> > potential for confusion in the usage of EndpointType.
> >
> > ET
> > --
> > ____________________________________________________
> > Eric  Tiffany             |  eric@projectliberty.org
> > Interop Tech  Lead        |  +1 413-458-3743
> > Liberty Alliance          |  +1 413-627-1778 mobile
> >
> >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail.  You may a link to this group and all your TCs
in
> OASIS
> > at:
> >
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]