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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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


Subject: RE: [security-services] more metadata questions...


Scott and I had a fairly lengthy conversation on Friday to discuss RSA's
metadata comments.  I promised him I'd write up what I think were the
conclusions. We'll be making some changes that we feel are actually
non-substantive and improve the overall clarity with respect to intent
behind some of the metadata items.

Scott, please jump in if I misspeak. And anyone else that wishes to
chime in, please do so.

The main issue was general confusion about the
<AttributeConsumerDescriptor> role.  The conclusion we reached was that
because the only defined use case we have for this is in the context of
SSO, it was decided that we should move most of the
<AttributeConsumingService> information into the <SPSSODescriptor>
element and remove the whole notion of <AttributeConsumerDescriptor>
from the metadata.  The processing logic doesn't really change, but it
eliminates the ambiguity that appeared when considering how a provider
that wanted to make Attribute Queries would utilize this metadata, since
it just doesn't make sense.

We contemplated adding new metadata for provider roles that truly
represent entities that make the various types of queries.  Settings
would indicate things like "WantAssertionsSigned", "AttrQuerySigned",
etc (but not any <saml:Attributes>).  But we felt that these roles would
require more substantive definition than we could add to the spec at
this point without triggering a new public review.  We can deal with
these items at some point down the road.

We also discussed the issue of a requester wanting to have the resulting
assertion and/or response message signed.  Scott suggested that it may
be most appropriate to indicate this in the protocol itself rather than
metadata.  We didn't reach a decision to add this to the protocol (so
assume we won't), but at least for now, we also won't include anything
additional in the metadata for it.

Rob Philpott
Senior Consulting Engineer 
RSA Security Inc. 
Tel: 781-515-7115 
Mobile: 617-510-0893 
Fax: 781-515-7020 
mailto:rphilpott@rsasecurity.com



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