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: Subject: PartnerID revisited



Following the discussion on last week's con-call here are some
voteable proposals:

(1) Proposal that the bindings group DROP further consideration of
the "modified" SAML artifact proposal, wherein the SAML artifact 
contains some "bounded-size" URL which can be directly used 
as the address of a artifact-to-assertion-lookup service.
 
Agree/Disagree 

[NOTE: There appeared to be consensus on the con-call to agree with this
proposition last week, so here is your last chance to object!]

 

(2) Proposal that the bindings document be limited to precisely the
following
web browser profiles:
 
(a) SAML artifact with a "small" bounded size artifact.
     (because of URL size limitations in existing browsers)
 
(b) FORM post.
 
Agree/Disagree
 
[I guess this is an "obvious" corollary of (1) but its always good to
 be concrete]
 
 
 
(3) Each site implementing the SAML artifact profile MUST select
a "Partner ID" URL. This URL MUST be drawn from a namespace owned or
controlled by the site. There are no further requirements for this URL, it
does 
not
have to be the address of a web page or a service or anything at all.
 
 
Agree/Disagree (please provide alternative and rationale)
 
[NOTE: This corresponds to the notion that the URL is being used to "name"
 the site only. We have given up on the notion that it stands for a "real"
resource or service]

 
(4) The SAML artifact be architected in the following way:
 
TypeCode: 0x0001
Partner ID: 20 byte SHA-1 hash of URL associated with the partner
AssertionHandle: exact format TBD but maximum size of 20 bytes.
 
Agree/Disagree (if you disagree please give rationale and alternative)



(5) [Bob Morgan] Proposition (4) overly constrains the PartnerID format. 
Its format should be left unspecified but with a maximum size (20 bytes). 
However, we would RECOMMEND that sites use the approach of (3) and (4). 

[After all, why should SAML intervene if a source site chooses to negotiate 
a partner ID with each of its destination sites or use some peculiar
PartnerID convention with each of its partners?]


Agree/Disagree


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


Powered by eList eXpress LLC