Minutes from SSTC Focus Call, May 4

["Mishra, Prateek" <pmishra@netegrity.com>]

May 4, 2003

Eve Maler
John Kemp
Bob Morgan
Scott Cantor
Jahan Moreh
Jeff Hodges
Rob Philpott

------------------------

1. SAML Public Key Authentication Methods 

 

http://lists.oasis-open.org/archives/security-services/200405/msg00001.html


John Kemp discusses the existing SAML AuthenticationMethod identifiers in
SAML 1.1.
For example, X.509, PGP, XKMS etc. 

Question: why were these chosen in this way?

But all of these are based on use of public-private key pairs and use of
signature.

Paul Madsen: that this can be accommodated by adding an additional element
to the 
existing AuthNContext definitions.

Scott, Bob: Maybe there is not enough context in the original definition
anyway, not very clear what
X.509 means, for example, could SSL-based mutual authentication fall into
this category?


Jahan: X.509 is not very descriptive, need more detail.

Bob Morgan: suggests we proceed with a fresh approach based on our current
understanding of these
matters. 

Eve: comfortable with this approach as long as migration issues are worked
out. 

AI: John to follow-up on this strategy and make a proposal to the list.


2.  Attribute Designator vs. Attribute

 

http://lists.oasis-open.org/archives/security-services/200405/msg00004.html

Scott: explains background to his message. Main issue is how to deal with
the case where an SP is only
interested in single attribute-value pair ("Is the user a member of Club
Med").


3. Federation Identifier Propagation

 

http://lists.oasis-open.org/archives/security-services/200404/msg00099.html

Discussion centers around propagation of federation identifiers from IdP to
SP.

Prateek: How does the IdP know that the SP received this identifier?

Scott: WHy does this matter?

Prateek: Because the IdP will later roll-over this identifier and receive an
error message for some users from the SP. 

Jeff: Not happy with changing AuthNRequest - Response interaction.

Prateek: Not proposing that but administrative model is a concern here. 


AI: Prateek to solicit information on deployment of federation models as
found in ID-FF 1.2. 
He will also write up his specific concerns.


4. 

[taking up the notes here at 1000h as prateek has to step out..]

SAML artifact discussion...

  scott cantor holding forth on artifact formats and how it is notated
  in bindings-..-09 and in metadata.

  lib metadata collapses anything that's soap-based into a single endpoint,
  but in samlv2 bindings & metadata, a binding can either claim a seperate
  endpoint, or one can use the (liberty-derived) "default" endpoint.

  so with the artifact binding, having only an endpoint in metadata might
  not be enuff. need artifact type here?

  Scott is questioning whether an artifact needs to be fixed in size,
  rather than simply constrained in size (and thus variable lgth). one
  thought is to put the providerId in the artifact which'd auger for
  having a varb-lgth artifact.

  if the providerId is in the artifact as the sourceId, then it's way
  easy to just dereference it to get the assertion.

  so we discussed this...Scott was just questioning the need to optimize
  around the edge case of "URL lgth constaints in the front channel", and
  the sense on the call was that yes, we really want the artifact to be
  constrained in size down to something pretty small because it will
  help ensure that we won't have tough-to-address issues coming out of
  left field, or from the mobile community (where URL lgth is way
  constrained), without us (the SAML spec-designing community) having a
  good answer (which is: "well, this thing is only 20 bytes long, we
  pretty much made it as small as we could, so mebbe you need to look at
  how much stuff you're trying to communicate across the front channel
  here while you're also trying to execute the AuthnReq/Resp protocol...")

  so then the question was which artifact type should we use, and decided
  that if we're going to accept the "short & fixed lgth" proviso, then we
  might was well re-use the Liberty ID-FF type format.

  AI: Scott will send a note to the list summarizing this recommendation.


We then adjourned.