RE: [security-services] ECP SSO Profile and Metadata

["Nick Ragouzis" <nickr@enosis.com>]

Well, what's so special about this profile? I suspect,
that it involves an active intermediary? And that the
ultimate receiver is, essentially, required to reach
*over* the semantics of the immediate connection (SOAP)
to infer and predict the modalities of its remote and
once-removed peer?

A metadata section would be good. And what will it say
that would change what's already there? You ... MAY ... 
publish metadata that says what the profile already
requires?

Well, the difference with the HTTP-* case is that you've
already received, directly (even if by proxy) the *peer's* 
message, and the bindings require you make your ultimate
response in kind (perhaps composed with Artifact).

Or is that all wrong?

--Nick

> -----Original Message-----
> From: Scott Cantor [mailto:cantor.2@osu.edu] 
> Sent: Thursday, June 23, 2005 08:27 AM
> To: 'Nick Ragouzis'
> Cc: 'SAML'; 'Thomas Wisniewski'
> Subject: RE: [security-services] ECP SSO Profile and Metadata
> 
> 
> > So, to resurect an earlier discussion:
> > 
> > > But sure, as a guideline, clearly any request ought to 
> really carry
> > > *something*. Leaving it out entirely usally seems like a bad idea.
> > 
> > Might it not be useful to require the ACSURL+binding/ACSIndex in
> > the <AuthnRequest> when via ECP? (And not changing the paos:Request
> > semantics.)
> 
> I don't really understand the point. Why not require it any 
> time? What's special about this profile? We didn't require it 
> because there's a defaulting mechanism, but defaulting only 
> works for one binding in a given deployment, obviously.
> 
> It's not a change to say that the profile, in terms of 
> metadata, presumes that the Binding in the SP is urn...PAOS. 
> It was simply left out, there was no metadata section in the 
> profile included like there should have been. Heck, we say 
> when you write a new profile, include metadata considerations!
> We didn't follow the rules.
> 
> I could just as easily be doing HTTP-* and not find a default 
> ACS with a compatible HTTP binding. Same problem.
> 
> -- Scott
> 
>