[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wss] SAML Token Profile 7 comments
Thanks Frederick. I will fold your comments into the next revision. Frederick.Hirsch@nokia.com wrote: >Comments on SAML Token Profile Draft 7, 5 May 2003, merged. > >Section 1, Introduction > >[53] Expand WSS: >"The Web Services Security SOAP Message Security specification ..." > >[54-57} revise wording for SAML >"This specification defines how Security Assertion Markup Language (SAML) assertions may be used with SOAP Message Security, including how they may be bound to the message and referenced from security headers." > >---------------------- >Section 1.1.1 Propose adding the following to replace TBS for this section [64]: > >This SAML Token Profile addresses the following two requirements: > > * SAML Assertion References >Define mechanisms for referencing SAML assertions carried in a SOAP Security header. This includes references to allow a SAML token to be signed (XML Signature ds:References), to allow a SAML token to be referenced as a source of key information (ds:KeyInfo reference), and potentially other references. These references take into account the inability of some SAML assertions to have an id attribute. > > * Binding SAML Assertions to a SOAP Message >Enable SAML assertions to be bound to SOAP Message content. This may be a direct binding where the SAML subject is the party attesting to the binding, or a delegated binding, where the attestation involves a party other than the subject. > >----------------------- >Section 1.1.2, Non-Goals. Add this text to replace TBS [67]: > >* Profiling SAML statement syntax or semantics (authentication, authorization, attribute statements). >* Use of SAML assertions outside the scope of the SOAP Message Security context. > >------------------------ >Section 2.2 Namespace >Although not final, the namespaces in the SOAP Message Security drafts are different from [89-90] and [92]. > >------------------------ >Section 2.3 Terminology > >[106] Revise definition term to include "Method": >"Subject Confirmation Method - the method ..." > >We should reference the SAML 1.1 Glossary committee specification and only have definitions here that are not in that glossary (avoid redefinition). > >So, I propose > >a) remove SAML Assertion Authority, Subject definitions >b) Add text: >Additional definitions related to SAML, including "SAML Assertion Authority", "Subject", and others may be found in the SAML Glossary [SAML-Glossary]. Add reference to SAML glossary to section 5. > >(We should propose that these additional definitions be added to the SAML glossary.) > >------------------------- >Section 3, Usage > >[117] Replace "security tokens" with "SOAP Message Security tokens". >[118-121] Remove the lines for Identification, Contact information, Description, Updates. > >------------------------- >Section 3.1 Processing Model > >This organization might be clearer: > >3. Referencing SAML Assertions >3.1 Mechanisms >3.1.1 SecurityTokenReference >3.1.2 ds:KeyInfo >3.1.3 ds:Reference >4. Processing Model >4.1 Attestation >4.1.1 Holder of Key >4.1.2 Sender Vouches >4.2 Application processing (describe here issues of choice, semantic labeling etc) > >Paragraph 2 [126-132] is very hard to understand. Perhaps an explanation of what it means to select signatures and assertions for processing is needed. Or, to say that the processing rules are application specific and out of scope of this profile. > >Where is the term "semantic labelling" defined? Does this mean the wsse:Usage attribute? If so, then that term should be used. >--- > >Section 3.3 > >I suggest we reorganize the first bullet list to reflect the order and priority of the references in the core specification, and add mention of Embedded References. > >---- >Thus: > >Direct References >Is the following a correct statement? if so we should update [202-209] accordingly, and also change [228]: (note that the example in 3.4.2.3 uses a direct reference) > >[205-209] >Although SAML 1.0 SAML assertions cannot be referenced with direct references since the AssertionID type is a string, SAML 1.1 assertions can, since the AssertionID type has been changed to be xsd:ID type, compatible with wsu:Id type. > >[228] >Key identifier and direct references are the preferred ways to reference SAML assertions that are not embedded. >---- >Key Identifier References >In this description replace the reference to SAMLBind with text as follows (line [187]: >"SAML protocol bindings are assigned a URI reference in the Oasis SAML Bindings document [SAMLBind]." > >[194-195] If an artifact is retrieved then it is clear that it is not an assertion, so it should be dereferenced. I do not think this should impact the core WSS spec. Should we add the following statement: > >When processing a remote SAML reference, if an artifact instead of a SAML assertion is retrieved, then this artifact must be further processed to retrieve the corresponding assertion. >---- >Key Name References >propose simplification [196-201]: > >ds:KeyName references MUST NOT be used to reference SAML tokens since there is no standard indication in a key name that it refers to a SAML token as opposed to some other key source. >---- >Embedded References >propose the following text: > >Embedded references may be used in conjunction with SAML assertions as shown in the SOAP Message Security specification example. >---- >3.3.1 SAML assertion referenced from header or element > >Change section title to >"SAML assertion referenced from wsse:SecurityTokenReference" > >[257] SecurityTokenReference start tag needs > >[275] Add quotes for Location value in second example, also closing > >----- >3.3.2 SAML assertion referenced from KeyInfo > >Change section title to: >"SAML assertion referenced from ds:KeyInfo" > >Note - examples seem to be obscuring text, possible formatting problem generating pdf? > >I argue, get rid of the text and examples in this section, since they add nothing new, and just state: > >To reference a SAML assertion from within ds:KeyInfo, it is recommended that a wsse:SecurityTokenReference element be placed within the ds:KeyInfo element and used as described in the previous section. > >---- >Section 3.3.3 SAML assertion referenced from SignedInfo > >[304] Change section title to: >"SAML assertion referenced from ds:Reference" > >The following might be clearer, showing what is referenced: > ><S:Envelope ...> > <S:Header> > <wsse:Security ...> > <saml:Assertion AssertionID="xyzzy">...</saml:Assertion> > <wsse:SecurityTokenReference wsu:Id="STR1"> > <wsse:KeyIdentifier wsu:Id="abc" ValueType="saml:Assertion"> > xzzy > </wsse:KeyIdentifier> > </wsse:SecurityTokenReference> > <ds:Signature> > <ds:SignedInfo> > ... > <ds:Reference URI="STR1"> > <Transforms> > <ds:Transform Algorithm="STR-Transform" /> > </Transforms> > ... ></S:Envelope> >... > >Should add text saying: > >A ds:Reference may also directly reference a SAML 1.1 assertion using a URI to the SAML AssertionID and specifying the reference type as "saml:IDReferenceType" as shown in the example in section 3.4.2.3". >--------------------------- >3.4 Subject Confirmation of SAML Assertions > >[335] Why do we say "especially RECOMMENDED" instead of MUST? > >[340] I suggest an editorial change to the table for readability: > >Method Identifier Rules >Direct 1 current text >Delegated 2 current text > >below the table have 1, 2 for the corresponding URNs >e.g. >1 - URN:oasis.... > >[342] s/messagesender/message sender/ > >3.4.1.3 Example >[397] >Do we want to use a SecurityTokenReference inside the KeyInfo elements in this example instead of KeyValue and show the linkage to an additional wsse:Security header token used to convey the key? > >I do not understand the /ds:Reference that precedes the first ds:Reference. Is there a reference missing in the example? Perhaps to the SAML assertion itself to bind it to the message? > >3.4.2.3 sender vouches example >[613] Here we demonstrate a direct URI reference to a saml assertion, rather than using an >STR transform reference. Should we also show using an STR Transform and add a SecurityTokenReference to the wsse:Security header to reference the >assertion? (as a second example) > >--- >3.5 Error codes > >[645] s/chose/choose/ >---- >5. References > >[748] SOAP 1.2 documents now at recommendation status >[762] SAML 1.1 committee specification or SAML 1.0 Oasis standard? >--- > >regards, Frederick > >Frederick Hirsch >Nokia Mobile Phones > > > >You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.php > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]