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

--

Hal
	- 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
groups

	- Phil
		- Take out substituion groups and replace with choice
groups.

		- Relevant in certain applications

--

Irving

	- 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

--

Irving

	- 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
assertion.

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

--

Phil
	- 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
users.

--
Irving

	- 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