I've posted the following message to the TC: http://lists.oasis-open.org/archives/xdi/201005/msg00004.html
Sorry I think those lists themselves aren't public, but the archives are. I'll let you know when there's good feedback on the matter. Markus On Wed, May 19, 2010 at 8:02 AM, Markus Sabadello < [email protected]> wrote: > Hello again, > > Good question.. First, note that the example messages at ibrokerkit.com(and > the XDI endpoints at > freexri.com and fullxri.com) are experimental and not in any way > standardized. However, I am convinced that there WILL be a standard set of > these messages supported by all i-brokers (and by the xdiFront component). > > Link contracts are also still under development by the OASIS XDI TC: > http://www.oasis-open.org/committees/xdi/ > > It is likely that the implementation of link contracts in XDI4j is not > currently fully in sync with the most recent patterns developed by the TC. > The best place of learning about those authoritative XDI patterns is here: > http://wiki.oasis-open.org/xdi/XdiRdfModel > > Regarding your question about $password, again, this is not (yet) > standardized in any way, but I think your proposal makes sense, i.e. a user > should always be able to freely operate on their own subject just by > providing the password! I could also imagine that there may be special link > contracts that grant permissions to anybody who knows a certain password. > > I will forward these questions to the XDI TC. > > Currently, in XDI4j, link contract enforcement on the server side is > implemented in the LinkContractAddressInterceptor class. Yes I could imagine > that this be extended to allow users to always have full rights on their own > subject! > > Markus > > > On Tue, May 18, 2010 at 5:32 PM, Nuno Rosa <[email protected]> wrote: > >> Hi Markus. >> >> Yes it really helped. I forgot to decode the key string. >> >> In the meanwhile if you could give a clarification on that flow: >> The message structure we send to the i-broker to retrieve account details >> (http://www.ibrokerkit.com/components/XdiFrontExamples/) >> >> =web*markus >> $is$a >> = >> $password >> "secret" >> $get >> / >> =web*markus >> +city >> +country >> >> >> If a subject has a $password predicate should the sender always be capable >> to operate on it (providing the secret) without signing the message and >> avoid link contracts? >> Will it be a part of XDI specification or let for implementors to decide? >> >> Thank you, >> Nuno R. >> >> 2010/5/19 Markus Sabadello <[email protected]> >> >> Hello Nuno, >>> >>> First of all, this is EXACTLY what we in the XDI world are envisioning, >>> i.e. a flow like this: >>> 1. User (or web service acting on behalf of user) retrieves >>> private/public key pair associated with the i-name. This is done by sending >>> an XDI message to the i-broker (e.g. freexri.com) that includes the >>> i-name's password >>> 2. User (or web service acting on behalf of user) can now send signed XDI >>> messages to XDI endpoints. >>> 3. XDI endpoints can discover the user's certificate using XRI resolution >>> and therefore verify the incoming XDI messages. >>> >>> Now to your question: >>> >>> I'm not familiar with the methods you are using. I normally do it like >>> this: >>> >>> import java.security.KeyFactory; >>> import java.security.PrivateKey; >>> import java.security.spec.PKCS8EncodedKeySpec; >>> >>> import org.apache.commons.codec.binary.Base64; >>> import org.eclipse.higgins.xdi4j.Graph; >>> import org.eclipse.higgins.xdi4j.messaging.Message; >>> import org.eclipse.higgins.xdi4j.messaging.MessageEnvelope; >>> import org.eclipse.higgins.xdi4j.messaging.Operation; >>> import org.eclipse.higgins.xdi4j.signatures.Signatures; >>> import org.eclipse.higgins.xdi4j.xri3.impl.XRI3Segment; >>> >>> public class Test { >>> >>> public static final String ENCRYPTION_ALGORITHM = "RSA"; >>> >>> public static void main(String[] args) throws Exception { >>> >>> String strKey = "MIIEwAI....."; >>> >>> KeyFactory keyFactory = >>> KeyFactory.getInstance(ENCRYPTION_ALGORITHM); >>> PKCS8EncodedKeySpec privateKeySpec = new >>> PKCS8EncodedKeySpec(Base64.decodeBase64(strKey.getBytes())); >>> PrivateKey privateKey = >>> keyFactory.generatePrivate(privateKeySpec); >>> >>> MessageEnvelope envelope = MessageEnvelope.newInstance(); >>> Message message = envelope.newMessage(new >>> XRI3Segment("=markus")); >>> Operation operation = message.createGetOperation(); >>> Graph operationGraph = operation.createOperationGraph(null); >>> operationGraph.createStatement(new XRI3Segment("=markus"), new >>> XRI3Segment("+email")); >>> >>> Signatures.sign(message.getSubject(), privateKey); >>> >>> System.out.println(envelope.toString()); >>> } >>> } >>> >>> Does that help? Let me know if you still have trouble or other >>> questions.. >>> >>> Markus >>> >>> On Tue, May 18, 2010 at 12:24 PM, Nuno Rosa <[email protected]>wrote: >>> >>>> Hi, >>>> >>>> freexri.com issued a certificate associated with my i-name and i got a >>>> private key to sign messages and grant authenticity; >>>> but i'm having a hard time trying to sign xdi message envelopes. >>>> Here's a snippet of my code: >>>> >>>> final String strKey = "MIIEvwIBADANB...." >>>> [...] >>>> DerValue dv = new DerValue(strKey); >>>> envelope.sign(PKCS8Key.parseKey(dv)); >>>> >>>> >>>> it throws the following error: >>>> >>>> *Exception in thread "main" java.io.IOException: corrupt private key* >>>> * **at sun.security.pkcs.PKCS8Key.parseKey(PKCS8Key.java:104)* >>>> * >>>> * >>>> * >>>> * >>>> Can you give me some hints, example on how to sign it? >>>> >>>> Best regards, >>>> Nuno R. >>>> >>>> _______________________________________________ >>>> higgins-dev mailing list >>>> [email protected] >>>> https://dev.eclipse.org/mailman/listinfo/higgins-dev >>>> >>>> >>> >>> _______________________________________________ >>> higgins-dev mailing list >>> [email protected] >>> https://dev.eclipse.org/mailman/listinfo/higgins-dev >>> >>> >> >> _______________________________________________ >> higgins-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/higgins-dev >> >> >
_______________________________________________ higgins-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/higgins-dev
