OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-bindings message

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


Subject: Minutes from Bindings con-call, Sep 20


Attendees: 
------------------
Marlena Erdos
Simon Godik
Scott Cantor 
Carlisle Adams
Tim Moses
Bob Morgan
Prateek Mishra
 
Two main issues of discussion: items (1) and (3) from the agenda
 
http://lists.oasis-open.org/archives/security-bindings/200109/msg00013.html
<http://lists.oasis-open.org/archives/security-bindings/200109/msg00013.html
> 
 
Agenda Item (1) 
- SAML artifact profile needed as browsers have limits on URL size
(IIS - 2000 chars) (Prateek, others)
 
   [?] Question about WAP browsers
   [Irving, Tim] WAP case may need separate treatment anyway, WAP browsers
   are still changing, 
   [Prateek] backwards compatibility will remain an issue
 
 
- consensus that a unique partner ID drawn from a managed namespace
  should be required for each source site participating in the Artifact web
browser
  profile (Tim, Scott, Hal e-mail, others)
 
   [Bob Morgan] This is over-specification, profile should not require this
   property, it is not required for inter-operability.
 
- some support for two different SAML artifact architectures; one carrying
  a "short" URL (address of artifact-to-assertion lookup service) 
  and second carrying SHA-1 hash of URL
 
   [Bob Morgan] What does a "short" URL really mean? What about multi-byte
character sets?
   Is this a practical architecture? Notice that some DNS names can easily
exhaust the
   "short" URL size restriction.
 
   [Irving] Concern about two different mandatory-to-implement architectures
that provide
   the same functionality
 
   [Tim] Both architectures need not be mandatory-to-deploy
 
   [Prateek] our products always require an existing business and  trust
relationship between source and destination sites, short "URL" will still
need to be checked against configured partner table
 
   [Scott] Shib is planning to use FORM Post profile
 
 [ACTION ITEM] Prateek to summarize and publish "next" set of voteable
positions on this 
 issue.
 
Agenda Item (3)
 [Simon] Relevant message is
http://lists.oasis-open.org/archives/security-services/200109/msg00007.html
<http://lists.oasis-open.org/archives/security-services/200109/msg00007.html
> 
 
[Simon] Interest in freeing current SAML artifact browser profile from
restrictions; there is value in treating artifact as a form of subject
 
[Marlena] current flows make too many assumptions concerning time when AuthN

assertion must be created; does not use full power of artifact as for
example in Shib
ANHQ proposal
 
[Prateek] Current flows are simple minded (an artifact always corresponds to
an assertion)
 but adequate. What flows of interest are excluded?
 
 [Tim] I have published an analysis of the flow of interest earlier. ACTION
item: will re-publish with link to Simon's message.
 
[?] If the pseudonymous case is supported within core assertions, then these
flows can
be accommodated in a two-step process. The first step pulls an AuthN
assertion using an
artifact; the second step queries for attributes.
 
[?] Sometimes, two steps is one step too many.
 
 
 
OTHER DISCUSSION:
 
[Scott] Interest in SAML XML-DSIG profile, what work has been done in this
space?
 
[Prateek] Krishna is active in this space, I have previously published note
on this. Will
re-publish link. 
 
 
 


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


Powered by eList eXpress LLC