I really like the new model. It seems to allow/encourage apps to have a single "data" (AppData) context that is managed for all RPs and separate disclosure events allow tracking what gets shared with which RP. This seems to be much cleaner and easier to understand for 99% of apps (including FormFilling). In addition, having each app have a single well known data context with a predefined UDI allows other apps to access data in other app's data.
However, in the case of Password Manager we either will end up with lots of RP specific personas in the AppData context, or we need a way to allow an app to create new RP-specific data contexts on demand. Also, we need to figure out how to have a UDI that means "this user's business address" that can also be shared by "user x" to "user y" and have it resolve to "user x"'s business address, not "user y"'s. One way would be for cards to be generated with different CardIds and have the UDI be derived in part from the CardId. That of course makes card distribution more difficult than if everyone could get the same "Address Card". Perhaps we should have a few "special" UDIs that when used by an AppCard's JS resolve to: - That AppCard's persona Resource UDI - That AppCard's AppData persona Resource UDI - Another specific AppCard's AppCard's persona Resource UDI (specified by AppId?) - Another specific AppCard's AppData persona Resource UDI (specified by AppId?) Regards, Michael McIntosh VP Development Azigo PS: Please update the example at the bottom of http://wiki.eclipse.org/Form_Filling with the new disclosure format -----Original Message----- From: Paul Trevithick [mailto:[email protected]] Sent: Saturday, September 18, 2010 9:08 AM To: Mike McIntosh Cc: higgins-dev developer discussions Subject: Modeling attribute disclosure Mike, I have updated the event vocabulary [1] to improve its support the "Disclosures" of personal data to relying sites: * relyingParty is now an explicit attribute (URI) * Disclosure events are now at the (finer grained) attribute level vs. entire context/cards * There is an "AttPolicy" class that allows "allow" vs. "block" policies to be recorded Here [2] is an example of an AppData context that has a Disclosure event (source file is "credit-bureau-app-data.n3" here [4]). Of course, other kinds of contexts (e.g. a ProfileContexts) could also have/use Disclosure events. Let me know if it needs any further tweaks. --Paul The source files [3, 4] have been checked in. [1] http://wiki.eclipse.org/Persona_Data_Model_2.0#event.owl [2] http://wiki.eclipse.org/Persona_Data_Model_2.0#Example_AppCard_and_AppData [3] https://dev.eclipse.org/svnroot/technology/org.eclipse.higgins/trunk/ontology/org.eclipse.higgins.ontology/ [4] https://dev.eclipse.org/svnroot/technology/org.eclipse.higgins/trunk/ontology/org.eclipse.higgins.ontology.examples/ _______________________________________________ higgins-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/higgins-dev
