Extensibility of SAML 2 metadata

[Keith Hazelton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Scott, Tom,

So for certs for non-SAML entity client auth purposes, is there a metadata spec-compliant way to add another descriptor element different from the current ones?  For argument's sake, something like 

<BambooAppDescriptor ....  >
...
</BambooAppDescriptor>

That would then provide a home for another Bamboo-specific key descriptor element.  Or am I off track?

           --Keith
_______________________
On Jun 20, 2012, at 08:59:33, Cantor, Scott wrote:

> On 6/20/12 9:04 AM, "Tom Scavo" <trscavo at gmail.com> wrote:
>> 
>>> I will note that this scenario is not SAML related, so maybe the answer
>>> is it doesn't belong in SAML metadata, extensions or not.
>> 
>> It *is* SAML-related. Back-channel exchanges (artifact resolution and
>> attribute query, e.g.) are examples.
> 
> Well, it may be similar, but that doesn't mean SAML. On the other hand,
> when you're doing security between servers with PKI, you have a handful of
> realistic choices:
> 
> - manual (assuming you can control what keys are accepted at the two ends)
> - full on PKIX, including revocation or OCSP
> - half-ass it
> - metadata-like mechanisms for key management, involving custom code
> 
> You can take a wild guess as to how most do it.
> 
> -- Scott
> 
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJP4goeAAoJEPXbVHOlscTvXQUH/0luuu6NKbgCl6dosCpRRIGg
4DzXo7Gl6o+cGq3ZT5VcerirAZSgyiI5KzIMEfzrw0y6HGk+L9B5BeCfrA1l4mLn
gHYHGXLmvmM5A/UpOHYQlUfZLqtZUs7u6zWBEGTBlUHfwZucwGmheH/T7lBShuBb
gJpmSeshOYfaZQPjO1tu7FsWUKU92kOTxCSOB1c8ONK89Clw5khKCbSc4dZm64Pd
SsBL6LZl9iymdyXwA7ZykKupX4kU6Ks6Uqcrr4s2UYONxvH97N4A5LEBP5N1ZMaD
ENlWqmZtD8SMUEx+guydtntiQ9uXqcha1uhi6TiTvOX2uUe/7vzRKPK5p2RYhj4=
=PtXH
-----END PGP SIGNATURE-----