|
From: Peter W. <ho...@ms...> - 2009-09-21 19:17:51
|
So I'm in two minds about the opensaml tooling lib Upgrading the whole type system for xrd in openxri to that lib is the right thing to do. Higher assurance requires formal methods, and secure type systems - where access and export constraints are enforced in such as a tooling lib. Proofs from info flow theory are possible, once one has a decent type system in charge. What I didn't like about that particular lib was it's philosophy for security service integration - as values are handled at the protection boundary. It's all fine as research, but not for folks mired in legacy infrastructure. On Sep 21, 2009, at 11:25 AM, Will Norris <wi...@wi...> wrote: > For right now, I know I'm planning on including the following basic > functionality in the OpenXRD library: > - XML marshalling and unmarshalling (provided by the XMLTooling > library, which was developed as part of OpenSAML) > - Message signing and signature verification > - Discovery of XRD documents. The default configuration will > likely use the discovery methods defined by LRDD (HTML <link> > element, HTTP response Link header, Host Meta). Other discovery > methods (such as DNS) can be registered as well. > - Selection of a linked resource based on a specified criteria > - Processing of URITemplates using registered template dictionaries > > I haven't yet worked out how much of the trust logic should be in > the library. I suspect that will depend on what XRD Trust profiles > look like once we get them written. Very likely there will be > implementations of the most common approaches provided, but in a way > that others can be easily used. The fact that we're using > XMLTooling for all of the XML handling may be enough of a deal > breaker for OpenXRI, I don't know. > > Peter, what "Shibboleth ideas for security infrastructure > management" is it that you are referring to that you don't want? Is > this something in OpenSAML that you've run in to previously? > > > Given that XRD is still a moving target (especially the processing > rules that have been in flux the last week), I've actually halted > development on the library until things settle down a bit so I can > focus on some other things. You can see what has been implemented > thus far at: > > http://svn.middleware.georgetown.edu/view/java-openxrd/trunk/ > > The unit tests will probably be the most useful for seeing how > things are expected to be used. > > -will > > > On Sep 20, 2009, at 9:48 AM, Peter Williams wrote: > >> That aligns largely with my thinking, except that I assume an >> better XRD >> interface should allow different runtime libraries to be plugged in. >> Reference libraries serve standards communities, but not user >> communities >> (as they typically stifle application, as the committee struggles >> to get >> consensus on funamentals). >> >> >> >> Im simply treating the XRD 1.0 format as a marshalling issue. And, >> of course >> one can have different serializations of the XRD type. During >> serialization >> of types to a wire format (e.g. XML), various signing and >> encryption scheme >> are performed - applying the commonly undertood art from the world >> of signed >> ASN.1 types (that have long spit out XML, as well as DER, PER, etc) >> >> >> >> The question is, will that "reference" library come loaded with >> Shibboleth/Internet2 conceptions of configuration, key management, >> crypto, >> etc. >> >> >> >> If so - and assuming its loaded full of all the usual Shibboleth >> ideas for >> security infrastructure management - I don't want it. >> >> >> >> I just want to marshall the current XRD type using the new bit >> format. Does >> it need to be any bigger any issue than that? >> >> >> >> From: mar...@gm... >> [mailto:mar...@gm...] On >> Behalf Of Markus Sabadello >> Sent: Sunday, September 20, 2009 3:55 AM >> To: Wil Tan >> Cc: Peter Williams; ope...@li...; Will Norris >> Subject: Re: [Openxri-users] FW: xrd 1.0 >> >> >> >> I know that Will Norris who is most active on the XRI TC is >> planning a >> reference implementation of XRD 1.0. >> >> I don't know the current state of this, but I think it would be >> straightforward that we at OpenXRI then use his library instead of >> implementing XRD ourselves.. >> >> Markus >> >> On Sun, Sep 20, 2009 at 4:31 AM, Wil Tan <dr...@gm...> wrote: >> >> Streams, as in, a sequence of documents, or a sequence of nodes in a >> document that is unending? >> >> >> >> It would be good to get the various parts of OpenXRI ready for XRD >> 1.0 (if >> they aren't already.) >> >> >> >> =wil >> >> On Sun, Sep 20, 2009 at 11:00 AM, Peter Williams <ho...@ms...> >> wrote: >> >> I built myself a responder that can produce xrd 1.0 (draft) streams. >> >> >> >> How might we in this community include and explore such code? >> >> Do we want to? >> >> Do our sponsors want this public? >> >> >> >> How might we allow folks to explore this, either in source or binary >> distiution? > > |