RE: [security-services] ECP profile question

Title: RE: [security-services] ECP profile question

Good idea.

 

From: Thomas
Wisniewski [mailto:] 

Sent: Thursday, February 02, 2006
3:05 PM

To: Brian Campbell;
; 

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:]

> Sent: Thursday, February 02,
2006 4:56 PM 

> To: ;
 

> 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:] 

> > Sent: Thursday, February
02, 2006 12:32 PM 

> > To: Brian Campbell;
 

> > 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:]

> > > Sent: Thursday,
February 02, 2006 11:14 AM 

> > > To: Scott Cantor;
 

> > > 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 

>