Re: [learningreg-dev] Publisher/creator/submitter/signer

20 views
Skip to first unread message

Steve Midgley

unread,
Dec 19, 2012, 7:49:40 PM12/19/12
to learnin...@googlegroups.com, <learning-registry-collaborate@googlegroups.com>
Hi Jerome,

Good to hear from you. Since we're working on updates and deletes in LR right now, your email is timely. Adding collaborate list b/c this is only semi-technical and of interest probably to both groups.

First off, as a general rule you should be signing documents using a public key that is long lived and well managed. So giving each user a key that they own is probably not great since users will leave and then you can't update their records easily. Most likely the key should be owned/maintained by your website or service and you should publish on behalf of your users. A simple rule might be "keys = websites/organizations." If you want to include identifiers for the users, like a twitter handle or something, we have a "signed on behalf of" approach, which hopefully Jim can detail for you. Not totally worked out but it permits a user identity within the signature from an organization.

If you as an organization sign the envelopes, then you don't care if the user leaves, you can still update their records. The big idea is that in LR anyone who controls the private key can update/delete a record signed using that private key.

We may also introduce the ability for node operators to permit "super keys" where someone who publishes updates/deletes signed with a superkey can modify records they don't own. This would be on a node-by-node basis, so there would be no superkeys across the federation.

So my rec is that you manage a single key, and publish user identities in other identity fields in the envelope and then use that key over a long period to update/delete envelopes as needed.

Jim or Walt will chime in if I'm giving bad advice, but I think that's the skinny.

Let us know what you think - we're still developing the solution so open to some input (though pretty far along in implementation so some stuff is baked already).

Steve




On Wed, Dec 19, 2012 at 8:11 AM, Jerome Grimmer <jgri...@siuccwd.com> wrote:

Hi guys,

We are writing code in preparation for publishing to the Learning Registry.  This is how we’re thinking of populating the publisher, creator, submitter, and signer fields.  Publisher and Creator are part of the nsdl_dc schema, which we will be using for publishing.  The other fields are part of the LR document.

 

Use case #1: PBS has made a Mr. Rogers Neighborhood episode available online.  John Jones of Timbuktu, Illinois elementary school decides to publish this resource through our web site.  We are thinking of assigning publisher, creator, submitter, and signer as follows:

 

·         Publisher: PBS

·         Creator: Fred Rogers

·         Submitter: Illinois Pathways

·         Signer: John Jones

 

Use case #2: John Jones has left the Timbuktu school district, and Beth Johnson has taken his place.  She wants to update the record and does so through our web site.  This time publisher, creator, submitter, and signer are:

 

·         Publisher: PBS

·         Creator: Fred Rogers

·         Submitter: Illinois Pathways

·         Signer: Beth Johnson

 

The reason for doing it this way is that John is no longer around to update the resource, but Beth is.  We can trust Beth’s update because though she is a different person, the submitter is the same.  This could also work in the case where you have multiple people in an organization submitting resources to LR.

 

Does this sound like a reasonable approach?  Is there any reason why we should not do it this way?

 

Jerome Grimmer

Southern Illinois University Carbondale

2450 Foundation Drive Suite 100

Springfield, IL

"If you think you're too small to make a difference, you've never spent a night with a mosquito." - An African Proverb

 

--
 
 

Jim Klo

unread,
Dec 19, 2012, 8:45:24 PM12/19/12
to <learning-registry-collaborate@googlegroups.com>, learnin...@googlegroups.com
Comments inline below:

On Dec 19, 2012, at 4:49 PM, Steve Midgley <steve....@mixrun.com>
 wrote:

Hi Jerome,

Good to hear from you. Since we're working on updates and deletes in LR right now, your email is timely. Adding collaborate list b/c this is only semi-technical and of interest probably to both groups.

First off, as a general rule you should be signing documents using a public key that is long lived and well managed. So giving each user a key that they own is probably not great since users will leave and then you can't update their records easily. Most likely the key should be owned/maintained by your website or service and you should publish on behalf of your users. A simple rule might be "keys = websites/organizations." If you want to include identifiers for the users, like a twitter handle or something, we have a "signed on behalf of" approach, which hopefully Jim can detail for you. Not totally worked out but it permits a user identity within the signature from an organization.

If you as an organization sign the envelopes, then you don't care if the user leaves, you can still update their records. The big idea is that in LR anyone who controls the private key can update/delete a record signed using that private key.

FWIW: Users signing their own envelopes might be okay in the future (see below), until the stuff below gets worked out… use a single key per organization...


We may also introduce the ability for node operators to permit "super keys" where someone who publishes updates/deletes signed with a superkey can modify records they don't own. This would be on a node-by-node basis, so there would be no superkeys across the federation.


I've floated an idea last minute last week among the team regarding 'super keys'… one idea that I had is that we could leverage the WOT model built into OpenPGP, that is each user key signs the super key's public material. And vice versa… through this the 'super key' algorithm used to authorize one envelope to 'tombstone' another via the checks on the keychain…

Assume key IL Worknet User signs key IL Worknet Admin.

IL Worknet Admin could publish an envelope that Tombstones IL Worknet User signed envelope.  The algorithm for authorizing the creation of tombstones could permit the the action if the key signing the original envelope also signed the public key of the key used to sign the Update/Delete envelope. Meaning that you'd have to do some upfront design decisions when employing this scenario.

Now assume all nodes trust a key LR Global Admin as a super key.
LR Global Admin signs the key IL Worknet Admin permitting it to be a super key as well.

In this scenario, because LR Global Admin signed IL Worknet Admin; anything signed by IL Worknet Admin could be permitted to update.  My concern with this side of the solution is node locking the super key or limiting the scope to prevent misuse.  i.e. I'm okay with every node operator having their own 'super key', however I'm not sure that all nodes should be automatically permitted to update any envelope in the system (envelopes that were published by some other node).

Because this whole piece hasn't been flushed out - we're not initially going to include any automatic way of doing this (unless someone can come up with a practical way to make this work). I think initially we'll support designating 1 or more super-keys in the node configuration… by default having no super key trust installed… forcing operators to make a conscious choice on who they allow to be a super key.


So my rec is that you manage a single key, and publish user identities in other identity fields in the envelope and then use that key over a long period to update/delete envelopes as needed.


For right now… this is the best approach..

Jim or Walt will chime in if I'm giving bad advice, but I think that's the skinny.

Let us know what you think - we're still developing the solution so open to some input (though pretty far along in implementation so some stuff is baked already).

Steve




On Wed, Dec 19, 2012 at 8:11 AM, Jerome Grimmer <jgri...@siuccwd.com> wrote:

Hi guys,

We are writing code in preparation for publishing to the Learning Registry.  This is how we’re thinking of populating the publisher, creator, submitter, and signer fields.  Publisher and Creator are part of the nsdl_dc schema, which we will be using for publishing.  The other fields are part of the LR document.

 

Use case #1: PBS has made a Mr. Rogers Neighborhood episode available online.  John Jones of Timbuktu, Illinois elementary school decides to publish this resource through our web site.  We are thinking of assigning publisher, creator, submitter, and signer as follows:

 

·         Publisher: PBS

·         Creator: Fred Rogers

·         Submitter: Illinois Pathways

·         Signer: John Jones

 

Use case #2: John Jones has left the Timbuktu school district, and Beth Johnson has taken his place.  She wants to update the record and does so through our web site.  This time publisher, creator, submitter, and signer are:

 

·         Publisher: PBS

·         Creator: Fred Rogers

·         Submitter: Illinois Pathways

·         Signer: Beth Johnson

 

The reason for doing it this way is that John is no longer around to update the resource, but Beth is.  We can trust Beth’s update because though she is a different person, the submitter is the same.  This could also work in the case where you have multiple people in an organization submitting resources to LR.

 

Does this sound like a reasonable approach?  Is there any reason why we should not do it this way?

 

Jerome Grimmer

Southern Illinois University Carbondale

2450 Foundation Drive Suite 100

Springfield, IL

"If you think you're too small to make a difference, you've never spent a night with a mosquito." - An African Proverb

 


--
 
 


--
You received this message because you are subscribed to the Google
Groups "Learning Registry: Collaborate" group.
 
To post: learning-regis...@googlegroups.com
To unsubscribe:learning-registry-collabo...@googlegroups.com
 
For more options, visit this group at
http://groups.google.com/group/learning-registry-collaborate?hl=en?hl=en

Damon Regan

unread,
Dec 20, 2012, 2:49:29 PM12/20/12
to learning-regis...@googlegroups.com, learnin...@googlegroups.com
Hi Jerome,

Will the recommendation to manage a single key, publish user
identities in other identity fields in the envelope, and then use that
key over a long period to update/delete envelopes as needed work for
you in the work you're doing at Illinois Pathways?

Best Regards,
Damon
> To unsubscribe:learning-registry-co...@googlegroups.com

Jim Klo

unread,
Dec 21, 2012, 3:32:41 PM12/21/12
to <learningreg-dev@googlegroups.com>, learning-regis...@googlegroups.com
Exactly… however… it would be advisable to add some unique token in the Submitter that your node can validate… I'm assuming with the way you're doing this… you'll have a private node that will sign on behalf of others?

The reason is the update 'should' technically fail because the submitter's don't match.  But according to the solution we are planning on moving forward with sign-by-proxy, the "verified" email address registered for publishing will be inserted into the submitter field:

"Illinois Pathways on behalf of John Jones <jjo...@verifiedemailaddress.com>"

It's possible we do something like this too where the token is just a hash of the email address… to obfuscate the email for the paranoid…

"Illinois Pathways on behalf of John Jones <969f41d22c41526862866db9a1a6af8d>"

When building this out… I plan on attempting to build some kind of plugin solution that you can customize the default validation logic….  your node would be responsible for allowing/disallowing the document to get published in the first place as an update…

Jerome, you seem to have a good use case - maybe we can talk more off list to flush out the situation, as I'd love to get your input… Even though we've closed the spec for update/delete to start implementation… I'd rather have a good use case to develop the validation for sign-by-proxy to work against.  This is my last day in the office until Jan… let me know if you have time in the new year to discuss.

- Jim

Jim Klo
Senior Software Engineer
Center for Software Engineering
SRI International
t. @nsomnac

On Dec 21, 2012, at 12:06 PM, Jerome Grimmer <jgri...@siuccwd.com>
 wrote:

I think that will work.  Just to check to make sure I have everything straight for the Mr. Rogers Neighborhood episode in my example:
 
·         Publisher: PBS
·         Creator: Fred Rogers
·         Submitter: Illinois Pathways on behalf of John Jones
·         Signer: Illinois Pathways
·         The envelope will be signed with Illinois Pathways’ private key, which can be verified with the Illinois Pathways public key.
 
Then when it’s updated by Beth Johnson (also of Timbuktu, Illinois elementary school), it will be handled this way:
 
·         Publisher: PBS
·         Creator: Fred Rogers
·         Submitter: Illinois Pathways on behalf of Beth Johnson
·         Signer: Illinois Pathways
·         The envelope will be signed with Illinois Pathways’ private key,, which can be verified with the Illinois Pathways public key.
 
Is this how we should be doing it?
 
Jerome Grimmer
Southern Illinois University Carbondale
2450 Foundation Drive Suite 100
Springfield, IL
NOTE: My E-mail address has changed
"If you think you're too small to make a difference, you've never spent a night with a mosquito." - An African Proverb
 
> 
> For more options, visit this group at
> en
> 
> 
 
--
You received this message because you are subscribed to the Google Groups "Learning Registry: Collaborate" group.
 
To unsubscribe:learning-registry-collabo...@googlegroups.com

--    

Jerome Grimmer

unread,
Dec 21, 2012, 3:46:08 PM12/21/12
to learning-regis...@googlegroups.com

 

Jim,

I’m actually working remotely today due to the weather.  This is also my last day until the new year.  I think a short conference call between us IT guys would be a good way to handle this.  I’ll bug my team and see if we can have an internal meeting first, then have a short conference call with you to hash this out.  Is that agreeable?

 

Jerome Grimmer

Southern Illinois University Carbondale

2450 Foundation Drive Suite 100

Springfield, IL

"If you think you're too small to make a difference, you've never spent a night with a mosquito." - An African Proverb

Steve Midgley

unread,
Dec 21, 2012, 4:32:11 PM12/21/12
to <learning-registry-collaborate@googlegroups.com>
Just to add a point of perceived clarification - I think Jerome is building some technology that will sign prior to publishing into LR (the "traditional" way of handling things). So the submitter field is totally controlled by his application I think? When doing "sign by node" stuff, we will need that submitter field to have some identifying information b/c only the node will be signing (and the node and the submitter will negotiate the identity before the node signs on behalf of the submitter).

I think there's more flexibility in Jerome's use case than in a node-signing use case but I'll leave it to you guys in conversation - just wanted to be sure that was clear in the dialogue..

Steve

Jim Klo

unread,
Dec 21, 2012, 7:42:16 PM12/21/12
to learning-regis...@googlegroups.com, learnin...@googlegroups.com
Today is my last day (hour, in fact) until the new year… this can certainly wait until after the holiday break.  It's all agreeable… we can tentatively hold this during the usual public LR design meeting slot which would happen on Thursday's @ 1PM PST. 

Would Jan 3 or 10 work for you?

- Jim

Jim Klo
Senior Software Engineer
Center for Software Engineering
SRI International

On Dec 21, 2012, at 12:46 PM, Jerome Grimmer <jgri...@siuccwd.com>

Kathleen Barnhart

unread,
Jan 10, 2013, 11:18:01 AM1/10/13
to learning-regis...@googlegroups.com
Googlegroups for the Learning Registry
--
Kathleen Barnhart
217.557.7323
Reply all
Reply to author
Forward
0 new messages