OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Metadata, IdP Disco, AuthnRequest, etc...


Hello --

We are developing around SAML v2.0, and we've come up with a few  
thoughts and questions that we'd like to run past everyone.

We would really like to have the samlp:AuthnRequest include  
saml:Attribute queries as well.  I've seen this mentioned on the list  
in a positive light by TC members, so I'm sure it's not anathema to  
everyone.  Has there been any work on defining this (extremely  
trivial) extension?  If not, I could certainly put together a document.

Has there been any discussion of in-band metadata exchange?  That is,  
metadata about the issuer/requester included inside an assertion or  
request?  This would be really helpful to minimize the amount of  
metadata management both IdPs and SPs have to do.  Some sites cannot  
necessarily rely on the out-of-band mechanisms defined in the  
metadata specification (ie, DNS or well-known URLs) for various  
reasons, so it'd be nice (and just as safe!) to have metadata  
exchanged as part of the communication.

Occasionally signed metadata is also unavailable or inadequate (no  
ds:KeyInfo, for example).  In these circumstances, it might be  
desirable to sign a SAML assertion or request with a SAML assertion.   
That is, the issuer of the SAML assertion (or the requester) acquires  
a SAML assertion authenticating it in the context of the larger  
federation, and then encodes that SAML assertion into another SAML  
assertion (or request), thereby authenticating that assertion or  
request.

Clearly it will be more complex than just putting the assertion or  
metadata in another assertion or request for security reasons, but  
the idea is that a given service provider or identity provider need  
not necessarily know anything about the requesting or responding  
party (prior to the transaction, that is).  If people are interested,  
I'd be happy to put together drafts with our current ideas for these  
two things and upload them to explain what we're thinking.

Along those same lines, why can't the IdP Discovery Service  
(optionally) return (signed) metadata about the requested IdP?  How  
does the IdP Discovery Service allow a SP to deal with participating  
in multiple federations simultaneously?  The service will redirect  
back to the SP, which will allow the SP to redirect to other IdP  
disco services, but

Finally, has there been any discussion on methods other than XMLSig  
or the Simple Sign POST profile (essentially, anything besides public  
key signatures) for authenticating SAML assertions?

Thanks!

KH

-- 
Karsten Huneycutt
Systems Specialist, ITS Identity Management
kph@unc.edu





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]