[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] Roles for SAML 2.0 Metadata
SAML is indeed extensible, in profiles. The metadata ("configuration
data") framework is -- as discussed on the last focus call --
extensible, allowing for the identification of config data for
additional participants within additional profiles. But the work of
defining the specific config data for specific participants in specific
profiles still needs to be done, if actual interop is to be achieved.
Jahan was asked to post a list of participants for which we should nail
down config data for V2.0. Given our decisions already made to date on
this work item, what's up for grabs now is not *why* to do things this
way, but rather *which* config data to cover for now.
(BTW, even if we were to reuse our attribute statement mechanism for
this information, which some have already pointed out is not a correct
use of SAML attribute statement semantics, we'd still be in the position
of defining *actual* attribute names and value spaces in order to
achieve the "config data" objective.)
Eve
Anthony Nadalin wrote:
> My point is why restrict. SAML should be extensible as new roles are
> identified as needing metadata, a provider's metadata can be extended to
> include its metadata for those roles w/o any changes to the specifications.
>
>
> Anthony Nadalin | work 512.436.9568 | cell 512.289.4122
> "Jahan Moreh" <jmoreh@sigaba.com>
>
>
>
>
>
> *"Jahan Moreh" <jmoreh@sigaba.com>*
>
> 12/29/2003 08:50 PM
> Please respond to jmoreh
>
>
>
> To: Anthony Nadalin/Austin/IBM@IBMUS,
> <security-services@lists.oasis-open.org>
> cc:
> Subject: RE: [security-services] Roles for SAML 2.0 Metadata
>
>
>
> Anthony -
>
> I don't believe this is a "restriction" at all. It is simply the case
> that SAML participants that need to exchange meta-data are identified by
> these roles. If there are any other roles that you believe we are
> missing, please enumerate some of them.
>
> Thanks,
> Jahan
>
> ------
> Jahan Moreh
> Chief Security Architect
> 310.286.3070
>
> -----Original Message-----*
> From:* Anthony Nadalin [mailto:drsecure@us.ibm.com]*
> Sent:* Monday, December 29, 2003 6:26 PM*
> To:* security-services@lists.oasis-open.org*
> Subject:* RE: [security-services] Roles for SAML 2.0 Metadata
>
> No I understood the purpose of the role, I still have a
> problem with the "meta role" restriction, I don't understand
> why the restriction.
>
> Anthony Nadalin | work 512.436.9568 | cell 512.289.4122
> "Jahan Moreh" <jmoreh@sigaba.com>
>
>
> *"Jahan
> Moreh"
> <jmoreh@sigaba.com>*
>
>
> 12/19/2003
> 12:53 PM
> Please
> respond to
> jmoreh
>
>
>
> To: Anthony Nadalin/Austin/IBM@IBMUS,
> <security-services@lists.oasis-open.org>
> cc:
> Subject: RE: [security-services] Roles for SAML 2.0 Metadata
>
>
>
> Anothny -
> I think you may have misunderstood my message. The concept
> of a "role" in this case is really that of a "participant".
> I.e., we are talking about the role that a SAML participant
> would take in communicating with another "participant". May
> be "participant" is also not a good name; may be we should
> call it a "meta role". In any case, this is specifcally NOT
> an arbitrary role that can be specified in an attribute
> assertion.
>
>
> Jahan
>
> ------
> Jahan Moreh
> Chief Security Architect
> 310.286.3070
>
> -----Original Message-----*
> From:* Anthony Nadalin
> [_mailto:drsecure@us.ibm.com_]*
> Sent:* Friday, December 19, 2003
> 8:09 AM*
> To:*
> security-services@lists.oasis-open.org*
> Subject:* Re: [security-services]
> Roles for SAML 2.0 Metadata
>
> Why is this restricted to any role
> this seems like an artifact of
> Liberty ? These should just be
> attribute assertions that any role
> can use.
>
> Anthony Nadalin | work 512.436.9568
> | cell 512.289.4122
> "Jahan Moreh" <jmoreh@sigaba.com>
>
> *"Jahan
> Moreh"
> <jmoreh@sigaba.com>*
>
>
> 12/16/2003
> 01:48
> PM
> Please
> respond
> to
> jmoreh
>
>
>
> To:
> <security-services@lists.oasis-open.org>
> cc:
> Subject: [security-services] Roles
> for SAML 2.0 Metadata
>
>
>
> Colleagues -
> During our focus group discussion of
> today (December 16), we recognized the
> need for specifying metadata for
> various roles. Our discussion lead us to
> believe that SAML 2.0 metadata
> should recognize the following roles:
> 1. Identity provider
> 2. Service provider
> 3. Attribute provider
>
> Do people have any thoughts/comments
> on this matter?
>
> Thanks,
> Jahan
>
> ------
> Jahan Moreh
> Chief Security Architect
> 310.286.3070
--
Eve Maler +1 781 442 3190
Sun Microsystems cell +1 781 354 9441
Web Products, Technologies, and Standards eve.maler @ sun.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]