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: Proposed text for adding ID of confirming entity


The minutes from the focus call are a bit off, I think. The substance of the
discussion and the statements by Gary and Ron indicated to me that the goal
was less about naming the "issuee", and more about naming the confirming
entity.

My proposal is fairly minimal in scope:

Insert at line 675 (definition of <SubjectConfirmation>:
<<<
<BaseID>, <NameID>, or <EncryptedID> [Optional]
Identifies the entity expected to satisfy the enclosing subject confirmation
requirements.
>>>

Insert at beginning of schema definition of the sequence:
<<<
		<choice minOccurs="0">
			<element ref="saml:BaseID"/>
			<element ref="saml:NameID"/>
			<element ref="saml:EncryptedID"/>
		</choice>
>>>

Notes:

My take is that all this really does is plug a hole in the spec in
representing the 5 "classes" of entity described in section 3.4 in the
discussion of the Authentication Request protocol:

Request Issuer
<Issuer> (on the protocol message, plus of course the authority is
represented by the same element)

Presenter
Not explicit, but this would actually correspond to the <IssuedTo> idea if
we added that too, so maybe that's not such a bad idea...

Requested Subject
<Subject>

Confirming Subject
This is the new addition, which is why I wanted it in <SubjectConfirmation>.

Relying Party
<Audience> or SubjectConfirmationData/@Recipient

-- Scott



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