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: [security-services] Fragment identifiers (again)


Steve proposes to adopt the XML Signature / RDF style of using fragment
identifiers for URI identifiers that we define in the spec.

E.G.

URI:
http://www.oasis-open.org/committees/security/docs/draft-sstc-core-26/artifa
ct

becomes

URI:
http://www.oasis-open.org/committees/security/docs/draft-sstc-core-26#artifa
ct


and so on:

http://www.oasis-open.org/committees/security/docs/draft-sstc-core-26#artifa
ct-sha1
http://www.oasis-open.org/committees/security/docs/draft-sstc-core-26#Holder
-Of-Key

We can then state in the spec that the base URI for derreferencing these
URIs is 

http://www.oasis-open.org/committees/security/docs/draft-sstc-core-26

And save ourselves a lot of typing 

#artifact
#artifact-sha1
#Holder-Of-Key

Ditto for RespondWith

#AuthenticationStatement
#AuthorizationDecisionStatement

etc.


BUT NOT for audience, target, location, binding etc. where the default is
not relevant.


This would mean minor changes to the wording of the description of using
URIs and the relevant parts of the spec.

	Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227

Phillip Hallam-Baker (E-mail).vcf



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


Powered by eList eXpress LLC