ER013 2119 terms for SC proposal

[Marc Goodner <mgoodner@microsoft.com>]

Here is my analysis for SC. The others will look the same when I get to them.

 

ER013 – SC

Changes needed

http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512

Line 236

If a token provides multiple keys then specific bindings and profiles MUST describe how to reference the separate keys

 

Line 356

In order for the security token service to process this request it MUST have prior knowledge for which Web Service the requestor needs a token

 

Line 612

the requestor is REQUIRED to re-authenticate the original claims in every renewal request

 

Line 757

Using a common secret, parties MAY define different key derivations to use.

 

Line 758

In order to keep the keys fresh (prevent providing too much data for analysis), subsequent derivations MAY be used

 

Line 784

The nonce seed is REQUIRED

 

Line 802

When a new key is required, a new <wsc:DerivedKeyToken> MAY be passed referencing the previously generated key

 

Line 843

then a fault such as wsc:UnknownDerivationSource SHOULD be raised.

 

English usages – No changes required

Line 192 “It should be noted”

Line 224 “Consequently producers of <wsc:SecurityContextToken> tokens should consider”

Line 229 “Care should be taken”

Line 316 “It should be noted”

Line 317 “As receipt of these messages may be expensive, and because a recipient may receive multiple messages”

Line 345 “As with all token services, the options supported may be limited.  This is especially true of SCTs because the issuer may only be able to issue tokens for itself”

Line 348 “SCTs are not required to have lifetime semantics. That is, some SCTs may have specific lifetimes and others may be bound to other resources rather than have their own lifetimes.”

Line 350 “it allows the optional extensions defined for the issuance binding including the use of exchanges”

Line 358 “This may be preconfigured although it is typically passed in the RST”

Line 365 “It should be noted”

Line 527 “It should be noted”

Line 534 “This binding allows optional extensions”

Line 608 “This binding allows optional extensions”

Line 611 “Because the security context token issuer is not required to cache”

Line 757 “For example, four keys may be derived”

Line 802 “When a new key is required”

Line 805 “then additional token exchanges are not required”

Line 875 “It should be noted”

Line 898 “then care should be taken”

Line 1025 “For a variety of reasons it may be necessary to reference a Security Context Token”

Line 1090 “It should be noted” “should be careful”

Line 1128 “It should be noted” “should be carefully reviewed”

Line 1130 “should be careful”

Line 1131 “It may be desirable to use running hashes as challenges that are signed or a similar mechanism to ensure continuity of the exchange.”

Line 1156 “It should be noted”

Line 1174 “Depending on the type of challenge used this may not be necessary because the message may contain enough entropy to ensure a fresh response from the recipient.”

Line 1188 “This request may or may not be secured depending on whether or not the request is anonymous”

 

All terms in section 10 are English and properly not capped, no change

 

Schema exemplar description changes

Many issues with OPTIONAL and REQUIRED in the schema exemplar descriptions. These are straightforward and I recommend that if the above is acceptable that the editors simply produce a redline version for review.