Skip to Content.
Sympa Menu

shibboleth-dev - RE: comments: draft-mace-shibboleth-arch-protocols-03

Subject: Shibboleth Developers

List archive

RE: comments: draft-mace-shibboleth-arch-protocols-03


Chronological Thread 
  • From: "Scott Cantor" <>
  • To: "'Tom Scavo'" <>
  • Cc: "'Shibboleth Development'" <>
  • Subject: RE: comments: draft-mace-shibboleth-arch-protocols-03
  • Date: Thu, 11 Nov 2004 15:05:42 -0500
  • Organization: The Ohio State University

> There is only one dashed line from User Agent to Identity
> Provider---it's the bottom half of step 3. This request is required,
> I think.

Nope, it's not. Processing can start with some combination of step 4-5, no
request assumed.

> Yes, but a picture would be best IMHO. There are as many different
> pictures as there are documents. I prefer the Liberty 1.2 diagram
> best. YMMV, of course. :-)

It does (I'm one of those people that don't find pictures helpful), but if I
have time I'll look at it.

> I didn't say "SOAP 1.1", just "SOAP". That covers both cases, right?

What about some other non-SOAP binding? The point is, we don't dictate the
binding, and we don't need to except perhaps in conformance, I'll see about
that.

> I was thinking that the same statement could be made about the
> assertion returned via artifact resolution, no?

No, I don't think so, since the Response in that case is the one associated
with the artifact request. And you can't return an artifact if there's no
assertion to match to it, so you can't even get anything over to the SP to
result in an error.

> Can you give a reference? (Btw, the SAML2 security doc still
> mentions the IdP.)

I thought it mentioned both, but I didn't review it. I know the SAML2
binding spec definitely includes the SP side. As for the paper, no, I don't
have a reference offhand...

> No different than requiring <md:IDPSSODescriptor>, right?

I think it's different, yes. One is self-evident, the other is a new
constraint we would be adding to the new metadata profile that only results
from our conformance requirements. I'll think about it.

> You probably should since they're making some implicit assumptions
> about Shib 1.3.

I will at some point, but Von participates in our calls when he's available.

> See specific comment submitted earlier.

I saw it, but that didn't really imply a whole section on it. We don't have
any new requirements around artifact resolution that would justify creating
a Shib profile. As far as metadata goes, the metadata profile will address
metadata usage for this step, though it doesn't yet. Greg and I will add it.

> But there needs to be some way to distiniguish the two authn response
> profiles in metadata. Is that forthcoming?

That's already in the profile I submitted. We use the SAML profile URIs as
the endpoint's "Binding". And we use this new URI from Shib as the Binding
of the SingleSignOnService endpoint, since that's our non-standard profile
for that step.

-- Scott




Archive powered by MHonArc 2.6.16.

Top of Page