From: Thomas
Wisniewski [mailto:Thomas.Wisniewski@entrust.com]
Sent: Thursday, February 02, 2006
3:05 PM
To: Brian Campbell;
jmoreh@sigaba.com; security-services@lists.oasis-open.org
Cc: Scott Cantor
Subject: RE: [security-services]
ECP profile question
Brian,
since there is a possibility that the responseURL may be relative (and this
would not be obvious from the proposed change), how about changing line 964 to
just:
/ecp_assertion_consumer
Tom.
>
-----Original Message-----
> From: Brian Campbell [mailto:bcampbell@pingidentity.com]
> Sent: Thursday, February 02,
2006 4:56 PM
> To: jmoreh@sigaba.com;
security-services@lists.oasis-open.org
> Cc: Scott Cantor
> Subject: RE:
[security-services] ECP profile question
>
>
> Here's a proposed correction
to replace the text in the description of
> PE35:
>
> The example on page 29 line
964 uses a ResponseConsumerURL of
> http://identity-service.example.com/abc.
Since this value must be an
> AssertionConsumerService at
the SP and must match (according to the
> rules in 4.2.4.4) the value of
the resonseConsumerURL, it is
> recommended
> to change it to
> https://ServiceProvider.example.com/ecp_assertion_consumer
(for
> consistency with other
examples in the section and to make the example
> on that would not result in an
error condition).
>
> > -----Original
Message-----
> > From: Jahan Moreh [mailto:jmoreh@sigaba.com]
> > Sent: Thursday, February
02, 2006 12:32 PM
> > To: Brian Campbell;
security-services@lists.oasis-open.org
> > Cc: 'Scott Cantor'
> > Subject: RE:
[security-services] ECP profile question
> >
> > I'll re-open the errata
and we can discuss on next call. If you have
> > proposed corrections,
please submit to the list.
> >
> > Jahan
> >
> >
> > > -----Original
Message-----
> > > From: Brian Campbell
[mailto:bcampbell@pingidentity.com]
> > > Sent: Thursday,
February 02, 2006 11:14 AM
> > > To: Scott Cantor;
security-services@lists.oasis-open.org
> > > Subject: RE:
[security-services] ECP profile question
> > >
> > >
> > > > > It seems
like this example would still require the
> ECP to send a
> > > SOAP
> > > > > fault
response to the service provider. No?
> > > >
> > > > I haven't
looked closely at it, but if they don't match, it's
> wrong.
> > >
> > >
> > > I believe it is
wrong so we should probably re-open that errata
> item.
> > >
> > >
> > > > > Why have
the AssertionConsumerServiceURL at all? Why not
> > > just have
> > > the
> > > > > ECP always
deliver the response to the responseConsumerURL?
> > > >
> > > > The IdP is the
one who knows where it's authorized to send PII
> about
> > > the
> > > > user to a given
provider. The client typically is deferring this
> to
> > > the
> > > > IdP
> > > > in order to
keep it minimal (but with the usual privacy costs).
> > > >
> > > > The cross-check
itself is to block a MitM attack where somebody
> > > intercepts
> > > > the SP's
response and redirects the ECP to tell it to send the
> > > response to
> > > > it. The IdP has
the metadata and the ECP authenticates it,
> > > so it knows
> > > if
> > > > it's being told
to send the response elsewhere,
> something's wrong.
> > >
> > > Fair enough.
> > >
> > >
>
---------------------------------------------------------------------
> > > 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_workgr
> > > oups.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_workgr
> oups.php
>