Skip to Content.
Sympa Menu

shibboleth-dev - attribute push

Subject: Shibboleth Developers

List archive

attribute push


Chronological Thread 
  • From: "Tom Scavo" <>
  • To: "Shibboleth Development" <>
  • Subject: attribute push
  • Date: Mon, 11 Sep 2006 07:49:00 -0400
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=IVkSIOAjUjFj8nO1ooYQxbEzNxGfh5kbxxwGJpgoURe6emPAdAfX/SDQ8O08R2PGVhiNxwrq5++7E0rt22Oe/6xVi/tcrN5wtGF935OtJe5YuZlK4o/skoEPURQL+DNqiEh6g6GM/kBelUzFWJzT8G4to/nVIh7hXwzE/4qPwmg=

What will a typical authn response look like in Shib 2.0? Will the
payload still be two separate assertions or are you considering one
assertion with two statements?

Assuming the authentication response contains two separate assertions,
will the Shib 2.0 SP continue to expose the complete response?

I missed the discussion of the SP at the F2F so I apologize in advance
if the following topic was covered. Instead of exposing the response
at the SP, why not expose the attribute assertion only (with the
response wrapper stripped away)? In that case, you end up with the
same thing irrespective of push or pull.

Also, why not nest the authentication assertion in the <Advice>
element of the attribute assertion? This exposes the authentication
context in its entirety and leaves it up to the consuming application
to make use of it or not, as the case may be.

Tom



Archive powered by MHonArc 2.6.16.

Top of Page