I've finally read the full OpenId spec and now have some questions related to unsolicited positive assertions.
When the OP creates an unsolicited positive assertion, is a private association created? If so where does this get stored or come from? If stored is there a data store extension point (override)?
I modified the OpenId OP and RP example sites to perform an unsolicited assertion. It does not appear to me, at least looking at the logs, that the RP performs direct verification of the unsolicited positive assertion. Is this correct? If no direct verification is performed, it seems to me that there must be a "stored" mutual shared key (MAC) being used and if so, is there an extension point (override) for storage and retrieval of the shared key associated with each OP/RP endpoint?
On Thursday, April 19, 2012 3:34:39 PM UTC-4, Richard Collette wrote:
> I've finally read the full OpenId spec and now have some questions related > to unsolicited positive assertions.
> When the OP creates an unsolicited positive assertion, is a private > association created? If so where does this get stored or come from? If > stored is there a data store extension point (override)?
> I modified the OpenId OP and RP example sites to perform an unsolicited > assertion. It does not appear to me, at least looking at the logs, that > the RP performs direct verification of the unsolicited positive assertion. > Is this correct? If no direct verification is performed, it seems to me > that there must be a "stored" mutual shared key (MAC) being used and if so, > is there an extension point (override) for storage and retrieval of the > shared key associated with each OP/RP endpoint?
Unsolicited assertions always use private associations. And the way the OP stores this is the same way it stores private associations for "dumb mode" RPs that can't store shared associations. In DNOA v3.x this was via the IAssociationStore if I recall correctly. In DNOA v4.x this is via the ICryptoKeyStore. And yes, they both default to in-memory stores that don't work well in web farm or other production environments but are extensibility points that should be implemented with a database backend for reliability and enhanced security.
> But the question on the private association still stands.
> Thanks > Rich
> On Thursday, April 19, 2012 3:34:39 PM UTC-4, Richard Collette wrote:
>> I've finally read the full OpenId spec and now have some questions >> related to unsolicited positive assertions.
>> When the OP creates an unsolicited positive assertion, is a private >> association created? If so where does this get stored or come from? If >> stored is there a data store extension point (override)?
>> I modified the OpenId OP and RP example sites to perform an unsolicited >> assertion. It does not appear to me, at least looking at the logs, that >> the RP performs direct verification of the unsolicited positive assertion. >> Is this correct? If no direct verification is performed, it seems to me >> that there must be a "stored" mutual shared key (MAC) being used and if so, >> is there an extension point (override) for storage and retrieval of the >> shared key associated with each OP/RP endpoint?
>> Thanks again for your direction. >> Rich
>> -- > You received this message because you are subscribed to the Google Groups > "DotNetOpenAuth" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/dotnetopenid/-/rv7ZfV-rhyQJ. > To post to this group, send email to dotnetopenid@googlegroups.com<javascript:_e({}, 'cvml', 'dotnetopenid@googlegroups.com');> > . > To unsubscribe from this group, send email to > dotnetopenid+unsubscribe@googlegroups.com <javascript:_e({}, 'cvml', > 'dotnetopenid%2Bunsubscribe@googlegroups.com');>. > For more options, visit this group at > http://groups.google.com/group/dotnetopenid?hl=en.
-- -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre
I just realized that after the assertion is verified, the RP further verifies that the "assertion matches identifier discovery results". If the entire unsolicited assertion is sent back to the provider and verified, wouldn't that then mean the identity within the assertion has already been verified? I'm not sure what the identity verification step accomplishes (or what bad thing it prevents from happening.
On Thursday, April 19, 2012 10:31:04 PM UTC-4, Andrew Arnott wrote: > Unsolicited assertions always use private associations. And the way the > OP stores this is the same way it stores private associations for "dumb > mode" RPs that can't store shared associations. In DNOA v3.x this was via > the IAssociationStore if I recall correctly. In DNOA v4.x this is via the > ICryptoKeyStore. And yes, they both default to in-memory stores that don't > work well in web farm or other production environments but are > extensibility points that should be implemented with a database backend for > reliability and enhanced security.
> On Thursday, April 19, 2012, Richard Collette wrote:
>> But the question on the private association still stands.
>> Thanks >> Rich
>> On Thursday, April 19, 2012 3:34:39 PM UTC-4, Richard Collette wrote:
>>> I've finally read the full OpenId spec and now have some questions >>> related to unsolicited positive assertions.
>>> When the OP creates an unsolicited positive assertion, is a private >>> association created? If so where does this get stored or come from? If >>> stored is there a data store extension point (override)?
>>> I modified the OpenId OP and RP example sites to perform an unsolicited >>> assertion. It does not appear to me, at least looking at the logs, that >>> the RP performs direct verification of the unsolicited positive assertion. >>> Is this correct? If no direct verification is performed, it seems to me >>> that there must be a "stored" mutual shared key (MAC) being used and if so, >>> is there an extension point (override) for storage and retrieval of the >>> shared key associated with each OP/RP endpoint?
>>> Thanks again for your direction. >>> Rich
>>> -- >> You received this message because you are subscribed to the Google Groups >> "DotNetOpenAuth" group. >> To view this discussion on the web visit >> https://groups.google.com/d/msg/dotnetopenid/-/rv7ZfV-rhyQJ. >> To post to this group, send email to dotnetopenid@googlegroups.com. >> To unsubscribe from this group, send email to >> dotnetopenid+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/dotnetopenid?hl=en.
> -- > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the death > your right to say it." - S. G. Tallentyre
The discovery step is required because openID 2.0 supports delegation. The claimed_id may not be in the same domain as the OP.
Without the discovery step to check that the OP is authoritative for that claimed_id you have zero security. Any OP can send a valid unsolicited assertion for any identifier.
John B.
On 2012-04-27, at 4:16 PM, Richard Collette wrote:
> I just realized that after the assertion is verified, the RP further verifies that the "assertion matches identifier discovery results". If the entire unsolicited assertion is sent back to the provider and verified, wouldn't that then mean the identity within the assertion has already been verified? I'm not sure what the identity verification step accomplishes (or what bad thing it prevents from happening.
> On Thursday, April 19, 2012 10:31:04 PM UTC-4, Andrew Arnott wrote:
> Unsolicited assertions always use private associations. And the way the OP stores this is the same way it stores private associations for "dumb mode" RPs that can't store shared associations. In DNOA v3.x this was via the IAssociationStore if I recall correctly. In DNOA v4.x this is via the ICryptoKeyStore. And yes, they both default to in-memory stores that don't work well in web farm or other production environments but are extensibility points that should be implemented with a database backend for reliability and enhanced security.
> On Thursday, April 19, 2012, Richard Collette wrote:
> DOH!. I just found the direct verification:
> But the question on the private association still stands.
> Thanks
> Rich
> On Thursday, April 19, 2012 3:34:39 PM UTC-4, Richard Collette wrote:
> I've finally read the full OpenId spec and now have some questions related to unsolicited positive assertions.
> When the OP creates an unsolicited positive assertion, is a private association created? If so where does this get stored or come from? If stored is there a data store extension point (override)?
> I modified the OpenId OP and RP example sites to perform an unsolicited assertion. It does not appear to me, at least looking at the logs, that the RP performs direct verification of the unsolicited positive assertion. Is this correct? If no direct verification is performed, it seems to me that there must be a "stored" mutual shared key (MAC) being used and if so, is there an extension point (override) for storage and retrieval of the shared key associated with each OP/RP endpoint?
> Thanks again for your direction.
> Rich
> -- > You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/rv7ZfV-rhyQJ.
> To post to this group, send email to dotnetopenid@googlegroups.com.
> To unsubscribe from this group, send email to dotnetopenid+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/dotnetopenid?hl=en.
> -- > --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre
> -- > You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/mfRM00kbz-8J.
> To post to this group, send email to dotnetopenid@googlegroups.com.
> To unsubscribe from this group, send email to dotnetopenid+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/dotnetopenid?hl=en.
On Friday, April 27, 2012 3:57:36 PM UTC-4, John Bradley wrote: > The discovery step is required because openID 2.0 supports delegation. > The claimed_id may not be in the same domain as the OP.
> Without the discovery step to check that the OP is authoritative for that > claimed_id you have zero security. Any OP can send a valid unsolicited > assertion for any identifier.
> John B.
> On 2012-04-27, at 4:16 PM, Richard Collette wrote:
> I just realized that after the assertion is verified, the RP further > verifies that the "assertion matches identifier discovery results". If the > entire unsolicited assertion is sent back to the provider and verified, > wouldn't that then mean the identity within the assertion has already been > verified? I'm not sure what the identity verification step accomplishes > (or what bad thing it prevents from happening.
> On Thursday, April 19, 2012 10:31:04 PM UTC-4, Andrew Arnott wrote:
>> Unsolicited assertions always use private associations. And the way the >> OP stores this is the same way it stores private associations for "dumb >> mode" RPs that can't store shared associations. In DNOA v3.x this was via >> the IAssociationStore if I recall correctly. In DNOA v4.x this is via the >> ICryptoKeyStore. And yes, they both default to in-memory stores that don't >> work well in web farm or other production environments but are >> extensibility points that should be implemented with a database backend for >> reliability and enhanced security.
>> On Thursday, April 19, 2012, Richard Collette wrote:
>>> But the question on the private association still stands.
>>> Thanks >>> Rich
>>> On Thursday, April 19, 2012 3:34:39 PM UTC-4, Richard Collette wrote:
>>>> I've finally read the full OpenId spec and now have some questions >>>> related to unsolicited positive assertions.
>>>> When the OP creates an unsolicited positive assertion, is a private >>>> association created? If so where does this get stored or come from? If >>>> stored is there a data store extension point (override)?
>>>> I modified the OpenId OP and RP example sites to perform an unsolicited >>>> assertion. It does not appear to me, at least looking at the logs, that >>>> the RP performs direct verification of the unsolicited positive assertion. >>>> Is this correct? If no direct verification is performed, it seems to me >>>> that there must be a "stored" mutual shared key (MAC) being used and if so, >>>> is there an extension point (override) for storage and retrieval of the >>>> shared key associated with each OP/RP endpoint?
>>>> Thanks again for your direction. >>>> Rich
>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "DotNetOpenAuth" group. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msg/dotnetopenid/-/rv7ZfV-rhyQJ. >>> To post to this group, send email to dotnetopenid@googlegroups.com. >>> To unsubscribe from this group, send email to >>> dotnetopenid+unsubscribe@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/dotnetopenid?hl=en.
>> -- >> -- >> Andrew Arnott >> "I [may] not agree with what you have to say, but I'll defend to the >> death your right to say it." - S. G. Tallentyre
> -- > You received this message because you are subscribed to the Google Groups > "DotNetOpenAuth" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/dotnetopenid/-/mfRM00kbz-8J. > To post to this group, send email to dotnetopenid@googlegroups.com. > To unsubscribe from this group, send email to > dotnetopenid+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/dotnetopenid?hl=en.
From a security point of view, it is discovery that tells you who the OP is for any identifier.
Normally that is done first and if the claimed identifier doesn't change you don't need to redo discovery if the RP is maintaining state.
The OP can change the claimed identifier to anything in the response. If that happens or if it is a unsolicited assertion then the RP MUST redo discovery.
I hope that helps.
John B.
On 2012-04-27, at 5:06 PM, Richard Collette wrote:
> Thank you for the response. I'll have to re-read the spec because the portion about delegation must not have stuck with me.
> On Friday, April 27, 2012 3:57:36 PM UTC-4, John Bradley wrote:
> The discovery step is required because openID 2.0 supports delegation. The claimed_id may not be in the same domain as the OP.
> Without the discovery step to check that the OP is authoritative for that claimed_id you have zero security. Any OP can send a valid unsolicited assertion for any identifier.
> John B.
> On 2012-04-27, at 4:16 PM, Richard Collette wrote:
>> I just realized that after the assertion is verified, the RP further verifies that the "assertion matches identifier discovery results". If the entire unsolicited assertion is sent back to the provider and verified, wouldn't that then mean the identity within the assertion has already been verified? I'm not sure what the identity verification step accomplishes (or what bad thing it prevents from happening.
>> On Thursday, April 19, 2012 10:31:04 PM UTC-4, Andrew Arnott wrote:
>> Unsolicited assertions always use private associations. And the way the OP stores this is the same way it stores private associations for "dumb mode" RPs that can't store shared associations. In DNOA v3.x this was via the IAssociationStore if I recall correctly. In DNOA v4.x this is via the ICryptoKeyStore. And yes, they both default to in-memory stores that don't work well in web farm or other production environments but are extensibility points that should be implemented with a database backend for reliability and enhanced security.
>> On Thursday, April 19, 2012, Richard Collette wrote:
>> DOH!. I just found the direct verification:
>> But the question on the private association still stands.
>> Thanks
>> Rich
>> On Thursday, April 19, 2012 3:34:39 PM UTC-4, Richard Collette wrote:
>> I've finally read the full OpenId spec and now have some questions related to unsolicited positive assertions.
>> When the OP creates an unsolicited positive assertion, is a private association created? If so where does this get stored or come from? If stored is there a data store extension point (override)?
>> I modified the OpenId OP and RP example sites to perform an unsolicited assertion. It does not appear to me, at least looking at the logs, that the RP performs direct verification of the unsolicited positive assertion. Is this correct? If no direct verification is performed, it seems to me that there must be a "stored" mutual shared key (MAC) being used and if so, is there an extension point (override) for storage and retrieval of the shared key associated with each OP/RP endpoint?
>> Thanks again for your direction.
>> Rich
>> -- >> You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.
>> To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/rv7ZfV-rhyQJ.
>> To post to this group, send email to dotnetopenid@googlegroups.com.
>> To unsubscribe from this group, send email to dotnetopenid+unsubscribe@googlegroups.com.
>> For more options, visit this group at http://groups.google.com/group/dotnetopenid?hl=en.
>> -- >> --
>> Andrew Arnott
>> "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre
>> -- >> You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.
>> To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/mfRM00kbz-8J.
>> To post to this group, send email to dotnetopenid@googlegroups.com.
>> To unsubscribe from this group, send email to dotnetopenid+unsubscribe@googlegroups.com.
>> For more options, visit this group at http://groups.google.com/group/dotnetopenid?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/kQZevlYTKOoJ.
> To post to this group, send email to dotnetopenid@googlegroups.com.
> To unsubscribe from this group, send email to dotnetopenid+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/dotnetopenid?hl=en.
