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] | [Elist Home]

Subject: FW: Minutes from 18-Sep focus concall

Minutes taken by Gavenraj.

Focus meeting - 18 Sep 2001

	- Straw poll on toll for Substituion groups
	- Intermediary, etc.
	- multiple name identifiers


	- Straw poll on tool for substition groups
		- Reads schema and builds classes (e.g., in Java)
		- Populate data structure from XML
		- Elimantated writing any parsing
		- Caster, an open source, does not support substitution

	- Phil
		- Take out substituion groups and replace with choice

		- Relevant in certain applications



	- Current schema has one or more subject

	- Based on XACML
		- How do you see it playing it out here

			- Don't want to have equivalent in there

	- When their are more than one subject
		- Role would be defined


What does go next??

	- Had a problem with equivalent
		- Need to rewrite section



	- Potential use case where assertion applied to combination of
subject.  Subject 1 is requester and Subject 2 is receiver.  
	- Carlisle:  Requestor would be put somewhere else in the

	- SAML should only have one n and one subject in assertion


	- Not suggseting we change cardinality, but in the case of a
subject field where it defines more than one (1) principle, name gets
specified jointly.
	- Not providing level of support if you are doing a set of


	- We should revisit what subject confirmation is.

	- What happens if we have 3 or 4 entities, we want consumers of
SAML information


Should be left open for people who use the specification.

	- Carlisle: Should not define what semantics should be.

	- Bob:  Two subject are the same:  attribute assertion should
define this.

	- Phil:  log file name may be different than person represented
(e.g., Phillip Hallam Baker is being displayed but phbaker is displayed
in the log file)

	- Equiavlent to subject - alt name
		- Bob: Should use as a Attribute assertion so we don't
have multiple subject fields.

	- Prateek
		- Would be really useful to only use this information
within one assertion.

	- Bob:  If you know name, you can code to find it.  If you
don't, you will have trouble.

	- Prateek:  Multiple assertions may not cause extreme confusion.
Relying party issue challenge to sender.  How is it implemented is out
of scope.

	- Bob:  Subject of Confirmation is the relying party to use.

	- Irving:  Subject of Confirmation is that assertion is meant to
be sent by the sender (generator of assertion).

	- We must not build reliability model for issuers.

	- Bob:  Subject Confirmation to relying party that attacks... 

	- Condition is represented by holder of key.  Confirmed holder
of key before relying.

	- To Carlisle's response, should be careful if having something
that looks like subject-alt-name.

	- Irving:  Implications may be spreading.  A single subject and
optional list of attributes and requesting authority send back
attributes about that subject.  

	- Marlena: You could put artifact in current schema

	- Spawn off of Bob Blakely's email.  Create thread with help
from Irving.!!!

	- Close of meeting.

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

Powered by eList eXpress LLC